If I understand #36603 correctly, you could solve the whole problem by letting your User class implement the EquatableInterface and simply ignore that specific role, couldn't you?

If I understand #36603 correctly, you could solve the whole problem by letting your User class implement the EquatableInterface and simply ignore that specific role, couldn't you?

My need is to add a specific role in order to inform the user she is under impersonation mode => display something visible enough to warn her. I don't understand I could achieve by comparing an AdminUser and a FrontUser for example.

My understanding from reading #36603 was that adding the custom role led to the user being logged out because it was seen has having changed. So if that's the case you could prevent the user from being treated as changed by implementing isEqualTo() and ignore your custom role there. So you can still check for the role being present in the rest of your application code.

Ok. Authentication prevents from same user change (affected roles have changed, it has been disabled, ...). It does not check if we move from one user to another user.

Let's see https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/Authentication/Token/AbstractToken.php#L255

I am sorry, but I do not understand what you mean with your last comment.

@alterphp Can you check if your original issue #36603 is fixed applying PR #35944 which fixes issue #35941?

Please don't use roles to check if impersonation is the case. The ROLE_PREVIOUS_ADMIN role is deprecated in 5.1.

You should create your own voter and check for a specific token instance. See for instance the implementation of IS_IMPERSONATOR:

@alterphp Can you check if your original issue #36603 is fixed applying PR #35944 which fixes issue #35941?

I'm pretty sure it will make my use case work, but, as I understant it, the PR simply removes the check that authenticator is supposed to do.

Please don't use roles to check if impersonation is the case. The ROLE_PREVIOUS_ADMIN role is deprecated in 5.1.

You should create your own voter and check for a specific token instance. See for instance the implementation of IS_IMPERSONATOR:

symfony/src/Symfony/Component/Security/Core/Authorization/Voter/AuthenticatedVoter.php

Lines 87 to 89 in e9be741

	if (self::IS_IMPERSONATOR === $attribute && $token instanceof SwitchUserToken) {
	return VoterInterface::ACCESS_GRANTED;
	}

The additional role is not used for authentication nor authorization, only to detect impersonation at the view level. It is a bad use ? I'm just trying to move the constraint of strictly using SwitchUserToken to a more extensible SwitchUserTokenInterface (that would not strictly require the original token).

@wouterj In a more simplier way, I'd like to use the existing AuthenticatedVoter (so removing ROLE_PREVIOUS_ADMIN and checking IS_IMPERSONATOR instead) but it strictly requires SwitchUserToken that itself requires an original token that is not suitable for cross-firewall impersonation...

I've removed the part using former ROLE_PREVIOUS_ADMIN usage.

@alterphp Can you check if your original issue #36603 is fixed applying PR #35944 which fixes issue #35941?

I'm pretty sure it will make my use case work, but, as I understant it, the PR simply removes the check that authenticator is supposed to do.

IMO the authenticator is supposed to check if the user has changed, but it is currently comparing user roles with token roles (as described in #35941).

The problem is that if you if you create a $token with an instance of an $user, and you add an additional role to the $token (not to the original $user), when you call $token->setUser($user) with the same $user instance used in constructor, the method $token->hasUserChanged($user) returns false, although you are using the same $user instance without any modification. It's a BC break introduced in 4f4c30d

IMO the authenticator is supposed to check if the user has changed, but it is currently comparing user roles with token roles (as described in #35941).

The problem is that if you if you create a $token with an instance of an $user, and you add an additional role to the $token (not to the original $user), when you call $token->setUser($user) with the same $user instance used in constructor, the method $token->hasUserChanged($user) returns false, although you are using the same $user instance without any modification. It's a BC break introduced in 4f4c30d

I think the check of different roles is intentional, but this should be confirmed by the core team.

I think the check of different roles is intentional, but this should be confirmed by the core team.

It could be intentional, but it's is a BC break, so that change should provide an upgrade path triggering a deprecation error.

Re-reading the whole thread, I don't think this is something that should be part of core. Closing. Thanks for proposing.