with this option enabled, the untracked_token_storage becomes useless if I'm correct ?
Does this PR really need to contains#33663 ?

@wadjeroudi yes it's needed, we still need to be able to differentiate usages that affect the response from others. See eg penultimate sentence in the description above.

Now tested functionally, PR ready on my side, waiting for#33663.

Status: needs review

Thank you@nicolas-grekas.

@aschempp please open a dedicated issue if you're suggesting we should change some things or discuss this further.

@aschempp here are some thoughts:

First of all, the statement that anonymous tokens are stateful "to track users" (#27817) seems incorrect to me, because anonymous tokens are not stored in the session

The session is still kept open for the browsing session so that it's possible to track users of the website (they wouldn't be "users of the app" from Security pov that's true).

What I find difficult to understand is the relation between anonymous users and lazy loading a firewall.

anonymous is the type where we know we can be lazy - ie we don't need to enforce any authorizations before allowing anything else on the app.

as soon as a non-anonymous user is needed, we need to check its authorizations before going anywhere further, which means starting the session eagerly. That's the relation to me, does this make better sense?

A firewall can choose to not have an anonymous authenticator, but lazily loading the session data might still make sense.

Not really, because the very first thing that must be done to ensure that one isnot anonymous is to start the session to know who is this non-anonymous.

The two are not related at all to me. This can be best seen by the changes in the SecurityExtension. Using the lazy loading context is decided upon not stateless and if anonymous is lazy. It's not anonymous that is lazy, it's the firewall itself, isn't it? Or rather stateless: 'lazy'?

We can make it lazy, but it would be resolved immedately, to do the check I mentionned just above.

On a side note, did you consider the problem that firewall listeners are no longer executed on their previous kernel.request priority (firewall defaults to 8) but can be executed anywhere in the code flow? I assume someone affected by this would simply need to disable lazy-ness?

Absolutely, that's the very reason why this is opt-in.

The two are not related at all to me. This can be best seen by the changes in the SecurityExtension. Using the lazy loading context is decided upon not stateless and if anonymous is lazy. It's not anonymous that is lazy, it's the firewall itself, isn't it? Or rather stateless: 'lazy'?

We can make it lazy, but it would be resolved immedately, to do the check I mentionned just above.

Ah, maybe that's what I got wrong. So essentially, wecould uselazy for non-anonymous (the code would work), but it does not make sense because it would always be resolved immediately? Is that also the case if there is noaccess_control in the security configuration? Can you tell what other service than routing needs the firewall user before any controller?

Btw. I'm on my way to SymfonyCon if you're interested to discuss this in person 🙃

@aschempp see you soon :)

Please have a look at#34358 and#34357 on the topic.

Is that also the case if there is noaccess_control in the security configuration? Can you tell what other service than routing needs the firewall user before any controller?

if you don't have any access_control in your configuration, enabling lazy mode would actually let user access your site anonymously (which should not be allowed) for any page not adding additional checks. That's why#34358 now forces the check in this case (which makes lazyness useless in this case as well)

Just to wrap this up 🙃
I finally got my head around whylazy only works with "anonymous: true": Because the firewall will not allow access to the route, if no user is logged in. Which means it can't be lazy. Until now I was assuming there would simple be no token instead of anAnonymousToken. But I agree that would not make sense.

However, quickly afterwards I told@Toflar "That wont work with REMEMBERME" and he remembered something about that, so we found#34679. I'll see about that and eventually contribute in the still-open PRs (instead of bugging you in a closed PR 🙈)