Users get sent to /_fos_user_context_hash upon login (ezpublish application)

[gggeek]

Not sure if it is a bug in FOSHttpCache, eZPublish or custom code.
The observed behaviour (no varnish, http cache on, ezp 5.4.5):

• user accesses the site
• gets redirected to /login
• fills in the form, posts to /login_check
• gets redirected to /_fos_user_context_hash

Since I fixed this by setting:

security:
firewalls:
ezpublish_front:
form_login:
always_use_default_target_path: true

I suspect that what goes on here is that the internal request made by Sf to retrieve the user-hash gets somehow 'remember' by the session as the last url visited by the end user just before logging in.

Any tips on fixing this in a more flexible way? Or is this really a bug?

[dbu]

is /_fos_user_context_hash under a firewall? that would be wrong. if it is not under a firewall, the request to the actually requested page should be after the hash lookup, and trigger the redirect to login, so the last access would be on the actually requested page.

having the hash url access protected is not an intended scenario. if the user is not logged in, that is also a context hash.

[gggeek]

@dbu the /_fos_user_context_hash is indeed under a firewall section, but it has "anonymous: ~" set.
Do you think that it should be added to a separate firewall with "security: false" instead ?
On a side note: are there any security implications into allowing /_fos_user_context_hash to be accessible by end users? Should we block access it at the reverse proxy (varnish) ?

[gggeek]

ping @andrerom @lolautruche

[andrerom]

@ggeek be aware we have blocked out 1.2.71.3.7 and higher as of 5.4.6 until @bdunoger's PR on the bundle gets merged/fixed. Are you on any of those FOS versions?

[stof]

@gggeek @dbu it cannot be under a separate firewall, as this is precisely about computing a hash based on the logged in user, and so needs the firewall to run to determine the logged in user.

What is needed is to prevent Symfony from storing this URL as the requested URL in the session.
See http://symfony.com/doc/current/cookbook/security/target_path.html for the way to exclude it from being stored (the example in the doc detects AJAX requests, which is now useless as the builtin logic handles it, but you can just put if ('user_context_hash' === $request->attributes->get('_route')) { there (adapt the route name to your needs)

[gggeek]

@andrerom I have seen the problem happening on both a community version of eZ (foshttpcache: 1.4.1, foshc-bundle: 1.3.6) and an enterprise version 5.4.6 (foshttpcache: 1.4.2, foshc-bundle: 1.3.7). Are you sure that the lockdown is in eZP 5.4.6 ?

[gggeek]

@stof thanks for chiming in. Do you reckon that the fix you mention could be added to the cacheBudle itself?

[gggeek]

PS: @andrerom I guess you meant "1.3.7 and higher", as there is no version 1.2.7 ?
If so, it seems that this is a separate bug, as it happened to us even on 1.3.6...

[ddeboer]

Just to clear up some confusion: /_fos_user_context_hash definitely needs to be inside a firewall. We can make the note in the docs on this clearer though: “… and make sure that this path is covered by your firewall configuration.”

I agree with @stof’s solution. It’s unfortunate that we have to override ExceptionListener, but I see no other way. @dbu Do you agree?

[andrerom]

PS: @andrerom I guess you meant "1.3.7 and higher", as there is no version 1.2.7 ?
If so, it seems that this is a separate bug, as it happened to us even on 1.3.6...

yes and yes, updated comment now that I'm not on phone :)

[dbu]

but why would the fos_user_context_hash route ever run into a security exception? it should return the hash for the anonymous user if there is no user credentials.

we can add a security exception listener in this bundle that is active by default and helps fixing a borked setup a bit. but i don't think things will work out as expected if something is misconfigured.

the example in the symfony doc should be updated by the way. its not only that the example is not relevant anymore but also that its using the class parameters which have been dropped in symfony 3 afaik.

[dbu]

btw, with the correct setup, i would expect there to be some issues with this feature. if /my/page redirects to login for anonymous users, we might have that cached - unless the security failure leads to making the page not cached. then every direct hit creates a new session and stores the url and happens to work out as the login is individual as well.

[gggeek]

@dbu

1. if I understand correctly, the security exception listener is only needed in cases where there is misconfiguration. In my case, I have no idea what the misconfiguration might be. I'd be happy to fix it the proper way if someone gave a tip on how to identity it.
2. I am sorry but your last comment is too complex for me: is "this feature" is the exception listener? and the issue is that /my/page would be cached for anon users, or that it would not be cached?

[dbu]

@gggeek

1. maybe try to "fake" the request with curl on the command line to see what you get back? there is a special accept-encoding header that varnish is sending, so just opening in a browser won't work. and look at the symfony logfile, having set log level to debug.
2. sorry that was a bit unclear. this feature meant "after login, redirect the user to the page he originally wanted to go to". if /my/page is in the firewall and thus triggers a redirect, if that redirect response is cached by varnish, redirecting the user after the login will not work because symfony never saw the request from that user. if each anonymous access to /my/page generates a hit on the backend however, you would get sessions that you reuse on /login and then do the redirect. if its a direct hit, this really should be the case as there should be a set-cookie header which makes the response un-cacheable.