Description
Hi,
(follow-up of #42650)
I believe our main goal for the new "security system" was to have always authenticated tokens, isnt it? As such i feel like make TokenInterface::getUser() nullable swaps a technical issue for a (severe) semantical one, defeating our initial goal. I want to verify it's 100% intentional.
I'd be able to bypass the passport user, and provide an unauthenticated token isnt it? Meaning i'm effectively re-introducing a AnonymousToken. But anonymous means token=null 🤔
So, IIUC, we're now back to $loggedIn = $token && $token->getUser(), rather than our initial intention $loggedIn = !!$token :) It looks like we're back at sqaure 1.
Confirmed here:
I dont think the check itself should require a service layer. Meaning we probably need better semantics for AuthenticationTrustResolver::isAuthenticated as well, or remove it. (btw calling it without args to me implies "the current token")
Now, to get back to "tokens are always authenticated" AND fix our technical issue in the voter subsystem i'd like to propose these alternative maybe-possible solutions;
- explore eg.
AnonymousUser / NullUser - introduce some signaling exception from getUser
- leverage some role name
vote(?TokenInterface $token)one way, or another :}
More side-related questions:
- how do we explain
TokenInterface::getRoleNamesvsUserInterface::getRoles, in both the current and previous architecture? What if i have a token with roles but no user currently? - is
CredentialsInterfacea pre-mature abstraction? Do we have another sementical issue given i could do the same usingSelfValidatingPassport+ badges? - Do we really need
AuthenticationTrustResolverInterface? rather than some static api.
Thanks :)
cc @chalasr, @nicolas-grekas , @wouterj also