Allow to easily ask Symfony not to set a response to private automatically #26681

Toflar · 2018-03-27T09:01:57Z

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets
License	MIT
Doc PR	symfony/symfony-docs#9667

This PR is related to the many discussions going on about the latest (Symfony 3.4+) changes regarding the way Symfony handles the session. I think we're almost there now, Symfony 4.1 automatically turns responses into private responses once the session is started and it's all done in the AbstractSessionListener where the session is also saved.
In other issues/PRs (#25583, #25699, #24988) it was agreed that setting the response to private if the session is started is a good default for Symfony. It was also agreed that setting it to private does not always make sense because you can share a response across sessions, it just requires a more complex caching setup with shared user context etc.
So there must be an easy way to disable this behaviour. Right now it's very hard to do so because what you end up doing is basically decorating the session_listener which is very hard because you have to keep track on that over different Symfony versions as the base listener might get additional features etc.

The FOSCacheBundle is already having this problem, Contao has the same issue and there will be probably more. Basically everyone that wants to share a response cache across the session will have to decorate the default listener. That's just too hard, so I came up with this solution. The header is easy. Every project can add that easily. It does not require any extension, configuration or adjustment of any service. It's clean, transparent and has absolutely no impact on "default" Symfony setups.

Would be happy to have some feedback before 4.1 freeze.

dbu

that would be much more elegant than the hacks we currently have to do. any possibility to get this (or something similar) into 4.1?

emodric · 2018-03-27T09:55:08Z

eZ Platform would also greatly benefit from this, since it also uses shared response across different sessions with the same user context.

stof · 2018-03-27T10:29:38Z

If you share a response between sessions, you still have an issue with the cookie header containing one of the session ids. How do you handle it in this case ?

emodric · 2018-03-27T10:31:10Z

@stof In eZ Platform case, and probably in FOS HTTP Cache bundle, Vary header does not contain Cookie header by default.

nicolas-grekas · 2018-03-27T11:38:16Z

src/Symfony/Component/HttpKernel/EventListener/AbstractSessionListener.php

-                ->setPrivate()
-                ->setMaxAge(0)
-                ->headers->addCacheControlDirective('must-revalidate');
+            if (!$response->headers->has('Symfony-NoPrivateIfSessionStarted')) {


This would allow cache poisoning if an external request comes with this header, isn't it?

Why would the response contain such a header based on an external request?

OK no sorry, I read it as a "request". What about using a request parameter instead?

This check should also be moved upper in the method.
The name of the parameter should be more accurate, eg session.disable_auto_cache_control or better?

I don't think this is correct. The question in that piece of code is

Hello response. I will now make you private if the session is started because that's what's a sane default. However, if someone wanted you to really be public even though the session is started, I'll leave you alone.

The subject is the response, not the request. Normally caching systems would add cache tagging headers to the response, set the cache control headers etc. It's all done on the response, never the request.

This check should also be moved upper in the method.
The name of the parameter should be more accurate, eg session.disable_auto_cache_control or better?

Why upper? Where exactly do you mean? And the parameter can be changed yes but as it's a header I think it should be more in the header naming style, no?

Toflar · 2018-03-27T11:42:22Z

@stof There's a lot more to consider, you are right. This is why Symfony defaults to setting the response private and it's what I meant by "requires a more complex caching setup". All this PR is about is that it's very hard to disable the current behaviour of Symfony and I don't think this is a good thing.

nicolas-grekas · 2018-03-27T11:48:05Z

But any new feature on Symfony would not be applicable to 3rd party bundles, unless they plan to support Symfony 4.1 only.
Since decorating this listener or adding a one next to it is all that is required, is it really worth it?

Toflar · 2018-03-27T11:49:53Z

I'm sorry but I don't think I understand what you're saying, @nicolas-grekas.

dbu · 2018-03-27T15:11:02Z

To illustrate the FOSHttpCache (and afaik ez publish) use case:

Caching proxy does a request to get a cache context token. Usually, this is md5 of all groups the current user is part of.
Caching proxy sends a request with a header Cache-Context-Hash using the hash it got, and also the original session cookie / auth header
Symfony handles the request, renders a response, and decides that the response does not depend on the actual user in question, but only on the roles of that user, and is thus cacheable with a Vary: Cache-Context-Hash

Its ok that symfony by default ignores what the application is telling about caching when the session has been used to generate the response. But for special cases like this, we need a way to disable this behaviour. Doing it with a response header seems the best solution because then it can be per response, but without needing a complicated configuration for the symfony listener as to which responses to handle or not.

For symfony 4.0, we simply decorate the SessionListener and only call the inner listener it when there is no Vary: Cache-Context-Hash header present. Symfony 4.1 breaks this solution, because the SaveSessionListener is now integrated into the SessionListener. Plus the SessionListener is now more complicated to improve lazyness. We started a pull request in FOSHttpCache to port most of that lazyness logic into our decorator, but it feels really complicated and clumsy, and might break again at any time because the coupling with Symfony itself is too high.

dbu · 2018-03-27T15:12:20Z

But any new feature on Symfony would not be applicable to 3rd party bundles, unless they plan to support Symfony 4.1 only.

We only register our decorator for symfony 3.4 or newer because before, the caching headers are not overwritten. If we can get such a solution into Symfony 4.1, we can limit the decorator to just 3.4 - 4.0

nicolas-grekas · 2018-03-27T16:08:08Z

@Toflar @dbu thanks for the details, OK on my side then :)

This check should also be moved upper in the method.

I mean as early as possible in the method, eg not sure we need to check for the session service at all.

Symfony-NoPrivateIfSessionStarted

this name is not accurate: max-age and must-revalidate also are removed.
What about Symfony-Session-NoAutoCacheControl?

Toflar · 2018-03-27T16:12:40Z

What about Symfony-Session-NoAutoCacheControl?

Naming things, right? 😄 Sounds perfect to me, changed.

nicolas-grekas

(never mind the comment about the place of the check, I missed the logic in the patched "if")

dbu

i was trying to think of an even better name but did not find any. this seems good enough. but i would make that into a constant, its also better in code using this as the relation would become explicit.

the class doc of the listener should be updated. it lacks mention of anything that is done with the response. i would say something like:

Checks if the session has been started and overrides the Cache-Control header to avoid all caching in that case. If you have a scenario where caching responses with session information in them makes sense, you can disable this behaviour by setting the header SessionListener::SESSION_NO_AUTO_CACHE_CONTROL on the response.

This listener also saves the session if it still open.

dbu · 2018-03-28T06:12:34Z

src/Symfony/Component/HttpKernel/EventListener/AbstractSessionListener.php

-                ->setPrivate()
-                ->setMaxAge(0)
-                ->headers->addCacheControlDirective('must-revalidate');
+            if (!$response->headers->has('Symfony-Session-NoAutoCacheControl')) {


imho this should be a public constant. then the constant can also be documented a little bit to explain what this is about.

Toflar · 2018-03-28T07:02:57Z

I agree but at the same time, I don't want to change a PR that has been approved already. Waiting for mergers to comment on that. BTW: Failing tests are unrelated.

nicolas-grekas · 2018-03-28T13:57:02Z

The const looks good to me.

Toflar · 2018-03-28T15:01:03Z

Done then, thanks for the feedback!

nicolas-grekas · 2018-03-28T16:04:03Z

src/Symfony/Component/HttpKernel/EventListener/AbstractSessionListener.php

 *
 * @author Johannes M. Schmitt <[email protected]>
 * @author Tobias Schultze <http://tobion.de>
 */
 abstract class AbstractSessionListener implements EventSubscriberInterface
 {
+    const SESSION_NO_AUTO_CACHE_CONTROL = 'Symfony-Session-NoAutoCacheControl';


and remove SESSION_?
AbstractSessionListener::NO_AUTO_CACHE_CONTROL_HEADER?

nicolas-grekas · 2018-03-28T16:04:28Z

src/Symfony/Component/HttpKernel/EventListener/AbstractSessionListener.php

- * Sets the session in the request.
+ * Sets the session onto the request on the "kernel.request" event and saves
+ * it on the "kernel.response" event.
+ * In addition, if the session has been started it overrides the Cache-Control


blank line need before

Toflar · 2018-03-28T16:11:30Z

Done.

…cally

fabpot · 2018-03-30T08:02:39Z

Thank you @Toflar.

…rivate automatically (Toflar) This PR was squashed before being merged into the 4.1-dev branch (closes #26681). Discussion ---------- Allow to easily ask Symfony not to set a response to private automatically | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | | License | MIT | Doc PR | This PR is related to the many discussions going on about the latest (Symfony 3.4+) changes regarding the way Symfony handles the session. I think we're almost there now, Symfony 4.1 automatically turns responses into `private` responses once the session is started and it's all done in the `AbstractSessionListener` where the session is also saved. In other issues/PRs (#25583, #25699, #24988) it was agreed that setting the response to `private` if the session is started is a good default for Symfony. It was also agreed that setting it to `private` does not always make sense because you **can share a response** across sessions, it just requires a more complex caching setup with shared user context etc. So there must be an easy way to disable this behaviour. Right now it's very hard to do so because what you end up doing is basically decorating the `session_listener` which is very hard because you have to keep track on that over different Symfony versions as the base listener might get additional features etc. The [FOSCacheBundle](FriendsOfSymfony/FOSHttpCacheBundle#438) is already having this problem, [Contao](contao/core-bundle#1388) has the same issue and there will be probably more. Basically everyone that wants to share a response cache across the session will have to decorate the default listener. That's just too hard, so I came up with this solution. The header is easy. Every project can add that easily. It does not require any extension, configuration or adjustment of any service. It's clean, transparent and has absolutely no impact on "default" Symfony setups. Would be happy to have some feedback before 4.1 freeze. Commits ------- 0f36710 Allow to easily ask Symfony not to set a response to private automatically

nicolas-grekas · 2018-06-26T21:35:44Z

@Toflar would you mind sending a doc PR to tell about this please?

Toflar · 2018-06-27T05:25:19Z

Done a while ago 😄 symfony/symfony-docs#9667

nicolas-grekas · 2018-06-27T05:38:57Z

Oups, sorry, I added the link in the description.

Toflar · 2018-06-27T06:36:29Z

Ah sorry, yes @javiereguiluz pinged me before the 4.1 release in a separate ticket so I forgot to update this one. Cheers!

guillaumedebeauvoir · 2018-07-02T15:07:57Z

@nicolas-grekas maybe i have missed something, but have you planed to make the same changes in 3.4 version, meaning adding the Symfony-Session-NoAutoCacheControl header to make cache behaviour same as before! If not i need to urgently rollback to previous version! I proposed a PR #27814 ! hope that will do it

yellow1912 · 2018-10-17T06:27:15Z

@nicolas-grekas Is this available in the latest 3.4.x, if not is there any plan to make it available?

nicolas-grekas · 2018-10-17T06:35:22Z

That's a new feature of 4.1, and 3.4 is in bug-fixes-only mode.

yellow1912 · 2018-10-17T07:05:16Z

Thank you, I will look into upgrading to 4.1, seems like tons of work. In the mean time, would there be an easy way to migrate this to the 3.4 version? I'm thinking of overriding the session_listener for Symfony and use the new code inside. Would that be a good approach? In such case should I run a compiler pass to remove the core session_listener definition then re-define it with my pass to point to my custom class?

nicolas-grekas · 2018-10-17T07:13:05Z

I don't remember where exactly but yes, a listener can do it also.
Note that you should first understand why this behavior is correct.
Then you can opt-out from it :)

Toflar · 2018-10-17T08:22:36Z

Yes, you can decorate the core listener. Can you tell me what exactly you're trying to do? I'm like 99% sure I have a better alternative for you where you don't have to do this at all or at least not on your own 😄

yellow1912 · 2018-10-17T08:31:19Z

@Toflar thank you for your response. My situation is that even with the session already started, I would like to be able to set the cache headers manually. NO_AUTO_CACHE_CONTROL_HEADER is exactly what I needed but I cannot upgrade to 4.1 at this moment (I'm on 3.4 and upgrading requires too much work that we cannot arrange the time at the moment)

What I ended up doing was:

Added a compiler pass

class SessionListenerPass implements CompilerPassInterface
{
    public function process(ContainerBuilder $container)
    {
        if ($container->hasDefinition('session_listener')) {
            $container->getDefinition('session_listener')->setClass(SessionListener::class);
        }
    }
}

Added my custom SessionListener with the onKernelResponse code take directly from 4.1 version

It seems to do the trick for now until I upgrade to 4.x version and remove this hack.

Toflar · 2018-10-17T08:32:53Z

Yeah basically that's what we did for FOSCacheBundle, which would maybe also cover your use-case, which is why I asked what you're trying to do :)

phillipsnick · 2019-01-16T17:42:27Z

Thanks @yellow1912 for the compiler pass idea!

carsonbot added Status: Needs Review Feature labels Mar 27, 2018

Toflar mentioned this pull request Mar 27, 2018

adjust to session listener changes in symfony 4.1 FriendsOfSymfony/FOSHttpCacheBundle#438

Closed

carsonbot added Status: Reviewed and removed Status: Needs Review labels Mar 27, 2018

dbu approved these changes Mar 27, 2018

View reviewed changes

nicolas-grekas reviewed Mar 27, 2018

View reviewed changes

nicolas-grekas approved these changes Mar 27, 2018

View reviewed changes

nicolas-grekas added this to the 4.1 milestone Mar 27, 2018

dbu reviewed Mar 28, 2018

View reviewed changes

nicolas-grekas reviewed Mar 28, 2018

View reviewed changes

nicolas-grekas approved these changes Mar 28, 2018

View reviewed changes

Toflar force-pushed the allow-disabling-auto-private-response branch from 6540ef3 to d85ba56 Compare March 28, 2018 16:11

fabpot approved these changes Mar 30, 2018

View reviewed changes

Allow to easily ask Symfony not to set a response to private automati…

0f36710

…cally

fabpot force-pushed the allow-disabling-auto-private-response branch from d85ba56 to 0f36710 Compare March 30, 2018 08:02

fabpot merged commit 0f36710 into symfony:master Mar 30, 2018

dbu mentioned this pull request Apr 5, 2018

adjust session listener to symfony 4.1 FriendsOfSymfony/FOSHttpCacheBundle#439

Merged

javiereguiluz mentioned this pull request Apr 20, 2018

Allow to not to set a response to private automatically symfony/symfony-docs#9647

Closed

Toflar deleted the allow-disabling-auto-private-response branch April 20, 2018 16:02

dbu mentioned this pull request Apr 21, 2018

Symfony 4 compatibility FriendsOfSymfony/FOSHttpCacheBundle#420

Merged

6 tasks

fabpot mentioned this pull request May 7, 2018

Release v4.1.0-BETA1 #27181

Merged

nicolas-grekas mentioned this pull request May 18, 2018

[HttpKernel] Fix response always private and overwritten if session is started #27282

Closed

Toflar mentioned this pull request Jun 26, 2018

Symfony 3.4.12 issue with 1.x? FriendsOfSymfony/FOSHttpCacheBundle#465

Closed

nicolas-grekas mentioned this pull request Jun 26, 2018

Auto add the cache-control headers? #25736

Closed

Toflar mentioned this pull request Aug 22, 2018

Consider the start/stop dates in cache timeouts contao/contao#13

Closed

Allow to easily ask Symfony not to set a response to private automatically #26681

Allow to easily ask Symfony not to set a response to private automatically #26681

Conversation

Toflar commented Mar 27, 2018 • edited by nicolas-grekas Loading

dbu left a comment

Choose a reason for hiding this comment

emodric commented Mar 27, 2018

stof commented Mar 27, 2018

emodric commented Mar 27, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nicolas-grekas Mar 27, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Toflar commented Mar 27, 2018

nicolas-grekas commented Mar 27, 2018

Toflar commented Mar 27, 2018

dbu commented Mar 27, 2018

dbu commented Mar 27, 2018

nicolas-grekas commented Mar 27, 2018

Toflar commented Mar 27, 2018

nicolas-grekas left a comment • edited Loading

Choose a reason for hiding this comment

dbu left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Toflar commented Mar 28, 2018

nicolas-grekas commented Mar 28, 2018

Toflar commented Mar 28, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Toflar commented Mar 28, 2018

fabpot commented Mar 30, 2018

nicolas-grekas commented Jun 26, 2018 • edited Loading

Toflar commented Jun 27, 2018

nicolas-grekas commented Jun 27, 2018

Toflar commented Jun 27, 2018

guillaumedebeauvoir commented Jul 2, 2018 • edited Loading

yellow1912 commented Oct 17, 2018

nicolas-grekas commented Oct 17, 2018

yellow1912 commented Oct 17, 2018

nicolas-grekas commented Oct 17, 2018

Toflar commented Oct 17, 2018

yellow1912 commented Oct 17, 2018

Toflar commented Oct 17, 2018

phillipsnick commented Jan 16, 2019

Toflar commented Mar 27, 2018 •

edited by nicolas-grekas

Loading

nicolas-grekas Mar 27, 2018 •

edited

Loading

nicolas-grekas left a comment •

edited

Loading

dbu left a comment •

edited

Loading

nicolas-grekas commented Jun 26, 2018 •

edited

Loading

guillaumedebeauvoir commented Jul 2, 2018 •

edited

Loading