Hmm, there is a problem. It's possible that an authentication mechanism could choose to create a token by using the roles from the User... plus some additional roles. In that case, on refresh, the roles are reset back to only the roles from the User. This actually happens in SwitchUserListener (

So this is tricky. We could make the feature more "opt-in"... but this is truly the correct behavior: token roles should refresh if they are changed on the User. It's surprising that they are not.

I can only think of one solution: if the Token roles != the User roles when the original authentication occurs, then we add some flag (in the session) that indicates that the roles should not be refreshed. Basically, if you are adding any custom roles beyond User::getRoles(), then you effectively opt out of us refreshing any of your roles.

Here's a summarized update:

1. If your token implements a new RefreshableRolesTokenInterface and its shouldUpdateRoles() method returns true, then when the refreshed User's role change, the tokens roles will also change.

2. AbstractToken implements RefreshableRolesTokenInterface, but returns false for shouldUpdateRoles(). So, by default, this new behavior is not applied (but see next point).

3. All core sub-classes of AbstractToken change the return value to its shouldUpdateRoles() so that they DO opt into the new behavior. However, there is some logic to it: they opt into this new "refresh roles" behavior ONLY if the original roles set on the token === the roles on User::getRoles(). This is to avoid an edge case: if an authentication mechanism stores extra roles on the token, beyond User::getRoles(). In this case, you do not want the token's roles refreshed to equal User::getRoles(), because you will lose your extra roles.

tl;dr

Most users will now have refreshed token roles when the refreshed User's roles change. A minority is security systems - where they purposely store extra roles in their token - will not benefit from this.

I believe I've safely added this behavior everywhere that I can.

Dont we have a UserChecker for these kind of things?

@weaverryan does this mean that when you are not using Doctrine to lazy/eagerly load roles via getRoles() on User object and instead some other way i.e. direct DBAL then in your refreshUser (if you implement UserProviderInterface) you'll have to ensure getRoles() returns roles as otherwise (here comes interesting bit) your roles will be purged if it returns an empty array (or "downgraded" to only ROLE_USER if you safeguard for empty collections in getRoles() implementation)?

@ptrm04 Hmm, yes, that's correct. And an interesting edge-case that I hadn't thought of. If you're (for some reason) not serializing your User's roles to the session or not refreshing them, then your roles would be lost. That's a slight BC break I hadn't thought of :/

@weaverryan status?

I won't have time to finish this thoughtfully for inclusion in 3.4. So, I'm changing the milestone to 4.1.

@weaverryan a clean implementation of the impersonation should not be using roles to store the old token (which requires using a custom Role object and not a string).
I actually have a working implementation of a cleaner system. But I don't know how to write a BC layer for it.

@stof I hope we will be able to make some big moves like the one you mentioned for 4.1 (and yea, BC is especially hard with security). For this issue, there are still enough edge-cases that I will need to make this new behavior opt-in.

Is there any progress in this matter?

I support the tentative.

For one of my applications I'm not able to migrate to newer version of Symfony because of the logout_on_user_change option as soon as the roles of a user can be modified after authentication.

Would be great to have a way to refresh the token easily without being logout.

@weaverryan Isn't it fixed by #31177?

It’s complicated - so I’ll check in greater detail in a few hours :)

Starting in Symfony 4.4 (thanks to #31177), if the roles on a user are modified (added or removed), the user will be logged out. That's not exactly what I was envisioning here, but that's the "safest" way for this to work.

Another way that the feature could work (and what I was attempting here) is that when the roles on a user are updated, on the next refresh, the roles in the token are updated. So, if ROLE_ADMIN were removed from a user in the database, on refresh, the user would no longer have that role (versus the current functionality where the user is logged out).

If someone is interested in that other way of making the system work, please open a pull request. I imagine that the idea behind this PR - and really the main code behind this PR - would still work. But there would need to be some way to opt-into the "refresh the roles" system... and make sure that the different roles on the 2 Users don't cause the user to be logged out. I'm not sure how to do that - but if you want the feature, you can create a PR and see if it can be figured out.

Cheers!

In case someone need to do it with Symfony 5.2 / ApiPlatform. In my case my app have 3 subscription plans with different roles. When the user subscribe to one plan I need to alter the subscription and so change the user roles. So the fact that Symfony properly logout after user changes is not good for user experience ... because you need to log in again after change.

Here is my workaround :
You manually set the isEqualTo function in order to not compare roles.

class User implements UserInterface, EquatableInterface
{
...
public function isEqualTo(UserInterface $user)
{
    if(!$user instanceof static){
        return false;
    }
    if($user->id !== $this->id){
        return false;
    }
    if($user->email != $this->email){
        return false;
    }
    if($user->password !== $this->password){
        return false;
    }
    if($user->getSalt() !== $this->getSalt()){
        return false;
    }
    return true;
}
...
}

@weaverryan Let me know if there is some security concerns about that.

@NathanDePachtere and with that, does it reload the roles for you? I'm using Symfony 5.1 now, with custom isEqualTo, however it never reloads updated roles.

@ptrm04 The isEqualTo() function should be triggered when calling setRoles(['YOUR_NEW_ROLE']) on your user. So user's roles should already be updated, don't need to reload something.

It's because you change roles that Symfony trigger its logic and compare user from session with your current user.

@NathanDePachtere the code you pasted won't reload roles automatically within symfony, it will only not log a user out when roles change. So you must be doing something else in your code if you are saying your roles get updated in the user object stored in the session. Afaik currently once the roles are set upon login they are "set in stone" until the user logs out and logs back in again.

I've created a documentation issue to update the docs to capture the recommended approach to reloading roles post-login: symfony/symfony-docs#14665

@ptrm04 I'm saying that the PHP User object is up to date not the session. As you mention you need to log back in if you want your session to be recreated and update.

The only other thing I do is on my front :
As soon as the user access my front there is a check if the user is login on the API or not, so if the session is invalid he will be asked to log back in.
This check is only done when accessing so if my user do something related to his roles he is not logout for the time he stays on the page.

Don't know maybe I'm missing something but for now this is working fine for my project.