Really interesting feature! Still, the web debug toolbar should force the display of authenticated status even when not necessary on the page since it could be very confusing for DX. But I have no relevant suggestion to make on how to deal with this...

A few questions:

• Does this mean that if my minimal authentication level isIS_AUTHENTICATED_ANONYMOUSLY, this option is useless? This will be quite some work to configure properly in an application, because you can't wild-card anymore with exceptions in access control (it is always triggered).
• Is this actually useful if you have even 1isGrantedanywhere? Let's say I have a small part where I always check if you're allowed to login or not, it would have to be rewritten to always check if there's a token first. But if I get the token, it will initialize, correct? Meaning this would make ESI impossible if you were to only check if you're allowed to login.

the web debug toolbar should force the display of authenticated status

that's impossible, by the very definition of what this feature achieves.

implementing a decoration for the actual_token_storage here

we need to access both the lazy and the actual storage services independently, so decoration cannot work here.

Does this mean that if my minimal authentication level is IS_AUTHENTICATED_ANONYMOUSLY, this option is useless?

yes, because this asks for an anonymous token.

Is this actually useful if you have even 1 isGranted anywhere?

as soon as you have one is_granted, the state is created, that's the purpose yes.

@nicolas-grekas 👍 won't the esi cache issue be fixed in the 3.4 branch ?

There is no issue in the 3.4 branch finally: enabling the anonymous firewall asks for the session. You'd need to fix your config here.

iltar: Does this mean that if my minimal authentication level is IS_AUTHENTICATED_ANONYMOUSLY, this option is useless?

nicolasgrekas yes, because this asks for an anonymous token.

I think this is a problem, becauseIS_AUTHENTICATED_ANONYMOUSLY can be used underaccess_control to basically mean "this URL requires NO security". But, we could fix this by adding some new way of doing this - e.g.roles: false under theaccess_control.

xavismeh: the web debug toolbar should force the display of authenticated status

nicolasgrekas: that's impossible, by the very definition of what this feature achieves.

This feature makes so much sense, that it should probably be on by default (and would, "effectively" be on by default thanks to the recipe update). But... this part IS a DX problem. Imagine if you're working on your authentication system, and itappears that it's not working, but really, it is.

IfContextListener never loaded the token, could we store the serialized token in the profiler data, and unserialize it there? This "laziness" should really be an invisible feature... and other than the profiler, I think it would be (e.g. because as soon as you try to "use" security, it would initialize itself).

@weaverryan it feels hacky though, but I think the main problem is the separation of the access_control rules and the firewall config. If that would be merged, it might solve problems (more than just this one). I'm currently just not able to figure out a viable alternative for this.

IS_AUTHENTICATED_ANONYMOUSLY basically mean "this URL requires NO security"

as you know that's no totally accurate, hence this PR :)

e.g. roles: false

roles: [] - or just no "roles" entry at all.

could we store the serialized token in the profiler data, and unserialize it there?

nope we can't: the session is the storage and we don't have direct access to the backend.

I don't think showing the truth is against DX. Actually, trying to hide the truth is the not-DX thing to me.
So here, we could display something that tells what the situation is: security is enabled but has not been used so we don't know who is here, anonymous or not.

as you know that's no totally accurate, hence this PR :)

but currently, there is no way to have an access_control rule requiring no security at all. So we indeed need to add a new feature.

So here, we could display something that tells what the situation is: security is enabled but has not been used so we don't know who is here, anonymous or not.

if the profiler also displays whether authentication was attempted or no, it could indeed help.

I found a better way, see#28089.

Reopening as there might be a reason to prefer this over#28089: here, the session lock is not created unless needed. But I would remove thelazy_authentication config entry and replace it withanonymous: lazy instead. See#28325

Continued in#33676