Added a short cookbook about avoiding the automatic start of the sessions #4661
Conversation
|
good one 👍 |
|
You also have to add a reference to |
| main: | ||
| pattern: ^/ | ||
| form_login: ~ | ||
| anonymous: ~ |
| anonymous: ~ | ||
|
|
||
| This behavior is caused because in Symfony applications, anonymous users are | ||
| technically authenticated. |
There was a problem hiding this comment.
is there any way to avoid this behaviour? or what is the recommended approach for this problem? using a different domainname for logged in users?
There was a problem hiding this comment.
This is a killer, but I'm not sure it's true (yay!). I just tested locally on a 2.6 project, and once I protected against the flash messages (using app.request.hasPreviousSession) and removed some session checks from my user-land code, there was no session cookie.
The security-related session stuff is handled in ContextListener. On kernel.request, it correctly doesn't start the session unless there was a previous session (https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Security/Http/Firewall/ContextListener.php#L76). Then, on kernel.response, it correctly doesn't save the token to the session if we're dealing with an AnonymousToken: https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/Security/Http/Firewall/ContextListener.php#L125
So for me, this note is not valid - but I wonder where you got this idea from @javiereguiluz? Is there something else?
|
great initiative, we really need this sorted out for proper caching. hacking around on varnish to remove session cookies most of the time has the tendency to break things in unexpected ways... could you add a section how to end the session again when there are no more flash messages / csrf tokens etc? that way, a user could get a session when he is on the form, but get rid of the session after success... |
| Avoid Starting Sessions for Anonymous Users | ||
| =========================================== | ||
|
|
||
| Sessions in Symfony applications are automatically started whenever they are necessary. |
There was a problem hiding this comment.
Sessions are automatically started whenever you read, write or even check for the existence
of data in the session. This means that if you need to avoid creating a session cookie for some
users, it can be difficult: you must *completely* avoid accessing the session.
For example, one common problem in this situation involves checking for flash messages, which
are stored in the session. The following code would guarantee that a session is *always* started:... then the code block
|
Thank you all for your reviews and comments. I've just updated this pull request. |
|
I like it! I think it's the best we can do in the docs - I'd like to see the code be more forgiving, but at least this is accurate and shows the hasPreviousSession() method. Thanks! |
…rt of the sessions (javiereguiluz) This PR was merged into the 2.3 branch. Discussion ---------- Added a short cookbook about avoiding the automatic start of the sessions | Q | A | ------------- | --- | Doc fix? | no | New docs? | yes | Applies to | all | Fixed tickets | #2607 Besides all the usual review, I'd like to ask doc reviewers to tell me if there is some way to avoid starting the session in the last case about defining a firewall that covers all URLs. Thanks in advance! Commits ------- bbba47a Added all sugestions made by reviewers 7dd3945 Added the new cookbook article to the global map 0212779 Tweaks and rewordings to improve the article 99781f8 Added a short cookbook about avoiding the automatic start of the sessions
Besides all the usual review, I'd like to ask doc reviewers to tell me if there is some way to avoid starting the session in the last case about defining a firewall that covers all URLs. Thanks in advance!