use tag for user context hash request invalidation

[dbu]

replace FriendsOfSymfony/FOSHttpCache#427
fix #482

[dbu]

@ranjzith can you check if this would work for you? i think this solution is more elegant than the BAN based approach even if we would make it work correctly.

@andrerom @lolautruche can you also look at this? i think it should work just fine, and also make the symfony httpcache setup more secure.

[ranjzith]

@dbu, thanks for adding me here. This is indeed a confident approach to invalidate user context response objects from caching server.

Just to acknowledge my understanding on the approach,

• Have all the user context hash responses tagged with user identifier header(session id).
• Send invalidation/purge requests for the session id tag using httpcache on logout handlers.
• No changes in the current VCLs in this case.

[andrerom]

Looks ok from my side, even if I'd like tag by user id too to be able to invalidate by on permission changes. That said we'll most likely end up having to purge by url in most of these cases in eZ Platform anyway as resolving affected user ids will be cumbersome and maybe not worth it.

However one thing to double check here:

• Check if the hash tag leaks into main request on Symfony Proxy, as that happened in some weird cases for me (on similar case in eZ Platform http cache which abstracts 1.x atm still), so I ended up not using tagger service in this case.

[dbu]

@ranjzith yes, exactly. tag handling is already implemented and with this solution there is no need to change anything on varnish to make this work.

@andrerom do you create a new session when permissions of a user change? you could also delete the tagged hash lookup in that case so the new hash is created in the next request. is there something general in symfony to know when permissions change that we could implement in the bundle? (i think not, i guess dynamic permissions is application specific, right?)

leaking the tag into the main request would be unfortunate. looking at what is happening:

• we have the user context plugin handle the hash lookup.
• in my understanding that should be a full request and its a master request
• however neither here nor here do we reset the tags. as this will be the same php process, we will indeed mess up here.

i fear this is a serious bug in the ResponseTagger - it will acumulate tags if used multiple times. do you agree that the correct behaviour would be for the ResponseTagger to empty the tag list after tagging one response with the tags?

[andrerom]

i guess dynamic permissions is application specific, right?

yes

i fear this is a serious bug in the ResponseTagger - it will accumulate tags if used multiple times. do you agree that the correct behaviour would be for the ResponseTagger to empty the tag list after tagging one response with the tags?

yes, it's a design issue.

I've been thinking a bit about that in regards to how this should be IF we where to propose moving tagging to Symfony itself. And been thinking trying to tie it to the request, and pass on to response once that is created or something to guarantee there is no sharing across requests. However don't think we can do that here easily, so just clearing it every-time we write the final response would be a good improvement on what we have.

[dbu]

i think tying it to the request could get complicated with subrequests - we want to only tag the actual response that is sent to the cache. symfony would not aggregate headers from different sub requests. i can't think of a sane situation where we have in-process master requests while handling a master request.

see FriendsOfSymfony/FOSHttpCache#430

[dbu]

this should now be ready.

@ranjzith can you check with this branch in your installation to make sure we really fix the problem with this?

@andrerom could you maybe verify in Ez if we do not mess up with tagging here?

[andrerom]

@andrerom could you maybe verify in Ez if we do not mess up with tagging here?

Code wise it looks ok. But as we are still abstracting 1.x, and my stab during summer at refactoring to use 2.x is non functional, so I have no way to test that.

[ranjzith]

With the changes I am facing couple of deprecation issues (I have PHP 7 and Symfony3.4 setup), couldn't really say its due to the changes but when I switch back to 2.4 branch everything gets back to normal. Sorry, could not test the changes right now with the setup.

[dbu]

are the deprecations related to FOSHttpCache though? 2.4.1...master is all changes we have since 2.4.1, which is not that much and i don't see how it would lead to deprecation warnings.

i will merge this but not (yet) tag a release and wait a bit for people to provide feedback.