That’s an excellent question, and what I read from the Spec Jakarta EE doesn’t know the concept of an anonymous user.
That means Jakarta EE and Spring are not using the concepts equally. From a Vaadin point of view, where the default runtime is Spring Boot, I would assume the same behavior in Vaadin as in Spring Boot.
In other words, @PermitAll should do the same as in the VaadinWebSecurity configuration.
Indicates that the given method or all business methods of the given EJB are accessible by everyone.
So probably, it should act exactly as @AnonymousAllowed.
I wonder if the current Vaadin meaning, that is similar to Spring authenticated(), should be achieved with and empty list in @RolesAllowed, but I cannot find any documentation about this case
I also have a vague recollection that we made @PermitAll be consistent with something else that was around at that time.
But now when it’s already used in one way, it would be a very dangerous breaking change to make it more permissive. That would be the case even in a major version since the change wouldn’t lead to any directly noticeable errors and we cannot assume that all developers read the release notes. We would basically have to explicitly disallow the use of @PermitAll for one or two major versions to weed out most usage and then re-introduce support with different semantics only after that.
I discussed this with a professor, friend of mine, who teaches Java EE and Spring Boot. We are of the opinion that Spring Security uses PermitAll incorrectly and that the concept of anonymous users is a strange one.
For this reason, I think the way Vaadin implements PermitAll is appropriate!
Ah okay. But yeah makes sense IMHO Vaadin uses it for frontend, when used in backend Spring interprets @PermitAll in another way. Strange but good to know!