Explore if user.roles.anonymous and user.roles.authenticated cache contexts can be combined

If user.roles.anonymous is 1, then user.roles.authenticated is always 0, and vice versa.

However, if one element adds user.roles.anonymous and another adds user.roles.authenticated, they could lead to additional cache redirects where a single cache entry would have been fine.

I am not sure the best way to handle this though. Maybe we could deprecate both and move to a user.is_authenticated or similar?

Keep in mind that even if we introduce 'user.is_authenticated', which I support, we can't stop people from using user.roles:anonymous or user.roles:authenticated as the user/roles cache context supports any role ID as its derivative value. We could, however, automatically convert them to user.is_authenticated, perhaps in CacheContextsManager?

Pros would be that old code keeps working, people don't have to know about this special case for these 2 user roles and we can gradually move all of core's usage to user.is_authenticated.

Just trying to avoid the obvious foot-gun by introducing a new solution and then leaving old solutions in, meaning we now increased the problem from 2 to 3 possible cache contexts saying the same thing, leading to even more unnecessary redirects.

Restoring title. I don't think the change was intentional.

Another thing to keep in mind is that if we have 'user.roles' and 'user.roles:authenticated' they end up folded as 'user.roles'. If we were to add 'user.is_authenticated' to that, we'd actually make performance worse rather than improve it. So if we end up filtering out user.roles:authenticated and user.roles:anonymous, we should only do so after we have folded the contexts.

Could we add user.roles.is_authenticated to the roles cache context - it would not be very semantic but it would enable all of the folding to happen in one place that way.

To be fair, while it does look semantically awkward, it would be technically correct, which is the best kind of correct. Whether or not you are authenticated is always translated into a specific user role in Drupal, so folding that info into user.roles when present makes sense.

The only thing we might still want to do is optimize user.roles:authenticated and user.roles:anonymous away into user.roles.is_authenticated. We could do that in CacheContextsManager but part of me dislikes that we would put specific code into an otherwise abstract class.

Ahh I see we can't do the folding in the UserRolesCacheContext ourselves because it just doesn't work like that...

We could trigger a deprecation if anonymous or authenticated is passed in, and encourage is_authenticated instead. And maybe do the optimization in CacheContextsManager as a temporary bc layer. Then in a future release, throw an exception if anon/auth is passed on telling people to use is_authenticated.

We could trigger a deprecation if anonymous or authenticated is passed in, and encourage is_authenticated instead. And maybe do the optimization in CacheContextsManager as a temporary bc layer. Then in a future release, throw an exception if anon/auth is passed on telling people to use is_authenticated.

Sounds like a solid plan.

#8++

I'm up for tackling this one once my schedule clears up a bit. Currently still focusing on Access Policy API