[Security] Support removing tokens from a session. #2414
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| if (null !== $this->logger) { | ||
| $this->logger->debug('Write SecurityContext in the session'); | ||
| } | ||
|
|
||
| $event->getRequest()->getSession()->set('_security_'.$this->contextKey, serialize($token)); | ||
| $session = $event->getRequest()->getSession(); |
There was a problem hiding this comment.
no, it may be null so it should be checked
|
This change looks good to me. In fact I'm using similar patch in my app and it works as intended. Also, several other people requested this on the mailing list. Could someone from Symfony team merge this? Thanks. |
| if (null !== $this->logger) { | ||
| $this->logger->debug('Write SecurityContext in the session'); | ||
| if ((null === $token = $this->context->getToken()) || ($token instanceof AnonymousToken)) { | ||
| $session->remove('_security_'.$this->contextKey); |
There was a problem hiding this comment.
Why would you want to remove the token if it is anonymous? I think we just need to remove it when it's set to null.
There was a problem hiding this comment.
Historically an AnonymousToken has not been persisted to session and is always created by AnonymousAuthenticationListener, when necessary. Seems good to keep that check and behavior.
fabpot
added a commit
that referenced
this pull request
Nov 7, 2011
Commits ------- ab9caa0 [Security] Check for request's session before attempting writes. dabff0e [Security] Support removing tokens from a session. Discussion ---------- [Security] Support removing tokens from a session. Currently there is no way to remove a session's security token without invalidating the entire session and all its data (the ContextListener will only update the session if a token is non-null and non-anonymous). This patch fixes that. I consider this a bug and I found no tests to prove otherwise. Let me know if I'm mistaken. Originally mentioned at https://groups.google.com/d/topic/symfony-devs/ojLvh0WUbfo/discussion Bug fix: yes Feature addition: no Backwards compatibility break: no Symfony2 tests pass: yes Fixes the following tickets: - --------------------------------------------------------------------------- by ms937 at 2011/10/24 05:19:21 -0700 This change looks good to me. In fact I'm using similar patch in my app and it works as intended. Also, several other people requested this on the mailing list. Could someone from Symfony team merge this? Thanks.
Merged
fabpot
added a commit
that referenced
this pull request
Nov 10, 2011
Commits ------- f9befb6 Remove only the security token instead of the session cookie. 348bccb Clear session cookie if user was deleted, is disabled or locked to prevent infinite redirect loops to the login path (fixes #1798). Discussion ---------- Fix for issue 1798 Bug fix: yes Feature addition: no Backwards compatibility break: no Symfony2 tests pass: yes Clear session cookie if user was deleted, is disabled or locked to prevent infinite redirect loops to the login path (fixes #1798). --------------------------------------------------------------------------- by snc at 2011/11/01 04:01:49 -0700 @stof I have changed the code so that it only removes the token... do we still need any hook support? --------------------------------------------------------------------------- by stof at 2011/11/01 04:07:17 -0700 well, the hook is for your own use case but it would be for 2.1 only anyway, not for 2.0 --------------------------------------------------------------------------- by snc at 2011/11/07 15:11:52 -0800 Now that #2414 is merged to 2.1, this could be simplified for the master branch...
fabpot
added a commit
that referenced
this pull request
Feb 4, 2013
This PR was merged into the 2.1 branch. Commits ------- 8ca00c5 [Security] fixed session creation when none is needed (closes #6917) Discussion ---------- [Security] fixed session creation when none is needed (closes #6917) | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #6917 | License | MIT | Doc PR | n/a --------------------------------------------------------------------------- by drak at 2013-02-04T16:24:49Z That looks good. Maybe we need a test for this logic to prevent any regression in the future? --------------------------------------------------------------------------- by bendavies at 2013-02-04T16:30:38Z Yep, this was exactly what i tried locally, but really wasn't familiar enough with it to be confident enough to submit it as a fix. Works for me! --------------------------------------------------------------------------- by bendavies at 2013-02-04T17:19:32Z A few test failures which were added by the breaking PR #2414 in the first place. --------------------------------------------------------------------------- by fabpot at 2013-02-04T18:00:31Z I've fixed the tests which now really test that the session is not started.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently there is no way to remove a session's security token without invalidating the entire session and all its data (the ContextListener will only update the session if a token is non-null and non-anonymous). This patch fixes that.
I consider this a bug and I found no tests to prove otherwise. Let me know if I'm mistaken. Originally mentioned at https://groups.google.com/d/topic/symfony-devs/ojLvh0WUbfo/discussion
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -