Note that the handling of the user switching needs to be refactored as it currently relies on a special role class. but the good news is that I implemented a similar feature at work in a way not relying on a custom role class. So I can refactor the Symfony system too.

That info could also be stored in the token attributes

@iltar this is exactly what my own implementation is doing. And it works totally fine (the hard part will be the BC layer)

What could be done if I'm understanding its inner workings:

• Add the info to attributes
• Throw a deprecation when it is an object
• if it's not an object and matches the string variant, check the attributes, else the role and throw a deprecation that the attribute should be set instead and a string role should be used

But I have to admit, never used the user switcher before, only a system where you can absorb roles to test stuff by impersonating.

@iltar the complexity of the BC layer is related to the parts allowing to check whether we are currently switching or no (which should not be handled by a role at all)

Just for understanding (don't want to re-ignit any discussion); why? Isn't it a step back going from objects to strings?

@afoeder there's no real benefit of using objects instead of strings. Eventually it just leads to overhead because you have to call Role::getRole()

There totally is, Usage Search! The safety of having objects. Refactoring abilities. Maybe stuff a particular Role does. Just OO.

We link custom data/privileges with user roles and people can define their own roles for a complex authorization system. Do we have to rework our code and move al that stuff to custom "roles" with their own voter?

There totally is, Usage Search! The safety of having objects. Refactoring abilities. Maybe stuff a particular Role does. Just OO.

+1 on this. In every cross-linked issue here it is pointed out, that this step was dicussed, but I can not find the discussion. With just reading the issues and comments I do not get why forcing ithe remove of the OO for roles is needed here. Afaik the role-string always needs the "ROLE_"-prefix (or is this changed?) and with this interface + class i could add this prefix to my roles which i fetched from the database.