Implemented Symfony reverse proxy support for user context hash.#152
Conversation
|
Travis fail seems to be only linked to HHVM. Didn't touch impacted part. |
|
yeah, HHVM is currently broken on Travis. It does not allow parsing XML files using an XSD |
There was a problem hiding this comment.
is this method needed ? Other places are relying on overwriting the constant itself
There was a problem hiding this comment.
Well, I actually left it here for convenience because of the code we have in eZ Publish. However I reckon that this I not very consistent...
bdb1fb5 to
de4ca66
Compare
|
OK, code has been updated and I added a test for new |
0a35388 to
c1a083e
Compare
|
+1 Just meta comment to add from my side; @dbu as this and also some earlier code is based on code from eZ Publish, would it be ok to add |
|
@andrerom The license mentions them because they are the original authors of the bundle (FOSHttpCache has been created by merging 2 bundles together). We don't update the license holder each time a new contributor appears. this looks good to me, but I will wait for @dbu to review as well |
|
Ok, clear. |
There was a problem hiding this comment.
is there nothing more explicit for this? if there isn't, this solution seems ok to me.
There was a problem hiding this comment.
Not that I could think about, there is no req.restart like in Varnish 😉
|
thanks a lot! very cool, and seems sane to me. i commented on a bunch of details. i really want to be paranoid and in doubt trade default performance for default security in case people misconfigured things. for the doc: i think we should have the HttpCache specific doc in its own chapter - i hope the kernel will provide at least purge/refresh at some point, even if ban is not very realistic. lets add a new file to the Features section named "Symfony2 HttpCache" that explains that instead of varnish or nginx you can also use this kernel. the doc would explain to extend our kernel and for the rest of the topic link to the relevant symfony core doc. then we should
|
There was a problem hiding this comment.
is this also done by symfony in other cases of internal requests? or is this your way of transporting the information that this is a valid request for the hash through the call to handle()? if its the later, can't we do this simpler, e.g. have a dedicated method that calls parent::handle at the end and have our handle() unconditionally refuse hash requests?
There was a problem hiding this comment.
It's not used anywhere in Symfony, this is just a convenient flag used in handle() method only. I don't understand your proposal. Example?
There was a problem hiding this comment.
remove this line, but in getUserHash do $this->handleInternalRequest which just calls parent::handleInternalRequest.
okay, i see the problem, if the user extends handle() it could be surprising. might not be the best idea then.
There was a problem hiding this comment.
So, can I leave it as is ?
There was a problem hiding this comment.
yeah i think its better than my proposal.
(just trying to challenge your solutions to see if it could be simpler)
There was a problem hiding this comment.
Syntax is not according to PSR.
|
@lolautruche lolautruche Can you fix the last few CS issues? Otherwise, I think we can merge this. |
|
@lolautruche can you please add a line to the CHANGELOG.md file? i would say add a title 1.1.x-dev and then something like |
7f31ece to
4f3c874
Compare
|
CS fixed and last request from @dbu taken into account (cookie string for user hash request). One request from me: Once merged, would it be possible to tag |
There was a problem hiding this comment.
thanks, i think this is more robust now.
|
One thing I’m noticing now: @lolautruche, you created protected methods in |
|
@ddeboer in one word: extensibility 😉 |
|
@ddeboer However, |
|
I think so, yes. But perhaps the other methods (except @dbu What do you think? |
4f3c874 to
106c4ed
Compare
|
Changed. But I kept |
There was a problem hiding this comment.
hm, i think we should keep this protected. i could have a different logic or support a legacy cookie or something like that.
Implemented Symfony reverse proxy support for user context hash.
|
Thanks for merging ! I guess I'll open a new PR |
|
i don't want to block you any longer, so i merged and tagged 1.1.0 ! i created #155 to track the question of basic auth. |
|
Thank you, @lolautruche! |
Finally the PR 😄
This adds support for Symfony RP for user context hash feature.
For this to work, you need to:
AppCacheclass extendFOS\HttpCacheBundle\HttpCacheinstead ofSymfony\Bundle\FrameworkBundle\HttpCache\HttpCache.USER_HASH_ACCEPT_HEADER,USER_HASH_HEADERandUSER_HASH_METHODconstants match your configuration (cannot rely on semantic config here as we're way too early for that).SESSION_NAME_PREFIXmatches your environment.In any case, it is possible to redefine those constants to fit your configuration.
TODO