This may be unrelated, but my custom guard authenticator now seems to regenerate the session on every request, and since most browsers make several concurrent requests, the ones that happen after the session has been destroyed all fail. To put it mildly, this is a bit of a problem :)

/cc @weaverryan

The changes from f6f2f97 (in particular the changes in the SimplePreAuthenticationListener) also break Contao. We have bound our authentication system to the PHP session ID, so whenever the PHP session changes, the user is logged out. And since the PHP session changes upon every request now, the user is logged out permanently.

BTW, should the session not only be regenerated after a successful login?

Same issue for me. Since I updated in 3.4.11 I have now all my form submissions which fails as it does not found csrf token in session.

Ill check into this. For anyone having the issue, can it offer more details? The session should only regenerate after a successful login, not on every request. If you can post some of our authentication code, like the authenticator & firewall - that may help.

@weaverryan pre-authenticated listeners are authenticating successfully on each request, as they send the credentials with each request

But, at the same time, any authentication mechanism that authenticates on every request would not need to use the session. The new code basically says:

A) I just authenticated. Is there a session?
B) If yes, migrate the session

My initial instinct is that we're hitting on a situation where some projects are both authenticating on every request, but also relying on the session. I'm not sure exactly why, so I'd like more detail from users. Specifically: if you notice that your session is being regenerated on every request, I'd like to see your authentication + firewall code. If you have this situation, then, for some reason, some authentication listeners IS "authenticating you" on every request, which causes the session regeneration.

@weaverryan I don't know if it is what you are looking for, but here is the authentication related stuff of Contao 4.4:

• https://github.com/contao-archive/standard-edition/blob/master/app/config/security.yml
• https://github.com/contao/core-bundle/tree/4.4/src/Security

@leofeyer yes - this is helpful :). Can you help me understand the ContaoAuthenticator? It creates an AnonymousToken then tries to find a user from by using the secret/providerKey passed to it? Can you describe the authentication flow that this class supports?

Also, I noticed that your firewalls are stateless. So, the Cantao authentication mechanism shouldn't care at all about the session, right? Btw, if you are available, I'm on the Symfony Slack if it's easier to dump some knowledge on me there (then I'd summarize here) :)

@aschempp will contact you. Thank you for your help!

Just chatted with @aschempp - PR proposal coming shortly.

For anyone else having issues, I would still like to see your authentication details. Contao has a very specific SimplePreAuthenticationInterface authentication situation. But, for those of you using Guard or something else, I still want to know your details.

See #27427.

But, I want to know more about users having issues - especially with guard authentication - to make sure we understand the full scope of things.

I've solved this issue in my instance by learning one very important thing: custom Guard authenticators which rely on sessions do not need to handle authenticated users. Guard already handles existing authenticated sessions if you don't get in its way.

In Symfony 3.4.11 my supports() method returned true for a login attempt, and also returned true if $request->hasPreviousSession() && $request->getSession()->has('username'), then my getCredentials() method would handle both situations, essentially handling every request as a login, which confused Guard.

I fixed this by removing everything except the handling of new login attempts from my custom authenticator and returning false from the supports() method at all other times. (It's slightly different for previous versions of symfony which don't implement the supports() method; in those, you'd make your getCredentials() method return null instead).

Thanks to @weaverryan for helping out on this.

Hi guys!

I now believe that this is entirely a documentation issue. Specifically, we should keep this session migration change. However, this does affect some authentication mechanisms. Specifically:

If you create an auth mechanism that you expect will be used by a browser, then your auth mechanism must be smart enough to not re-authenticate the user when they are already authenticated

If your browser-based authentication mechanism IS authenticating the user on every request, then you actually do need to migrate the session, else you're open to session fixation. That's exactly what the recent patches added. So, if you are in this situation, I believe the proper fix is to update your authenticator to only authenticate when necessary (i.e. not on every request).

I've created a docs PR - symfony/symfony-docs#9860 - for the 2.8 version with Guard. You can see an example of checking to see if the user is already authenticated.

Hi again!

After a bit more chatting, I believe there is still a problem. Specifically, the session should not migrate if your firewall is stateless: true. The use-case is SSO - e.g. your auth mechanisms reads from $_SERVER on every request to auth the user.

With the recent changes, even if you set stateless: true, your session is still migrated. I believe that's wrong, as there should be no risk of session fixation. And, practically speaking, any stateless, SSO implementation will suffer this problem.

I think the only solution is to, somehow, make the session migration process aware of whether or not the firewall is stateless. Rolling back the changes it not really an option, as we would need to rollback the changes to Guard, but Guard truly does need to migrate the session in the vast majority of cases.

I think the only solution is to, somehow, make the session migration process aware of whether or not the firewall is stateless.

I agree.

See #27452

I hope everyone who kidnapped this ticket got a solution ;-)

My original concern was not referring to the latest changes in session migration which seems to have caused that problem, but to a change introduced in Symfony 2.3. Would you be so kind to have a look at that @weaverryan and/or possibly others? Thanks!

@weaverryan can this be closed ?

Thank you for this suggestion.
There has not been a lot of activity here for a while. Would you still like to see this feature?

Could I get an answer? If I do not hear anything I will assume this issue is resolved or abandoned. Please get back to me <3

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!