On 21/11/2016 10:45, Osipov, Michael wrote:
> Hi folks,
>
> I am currently porting our custom Tomcat components from 6.0 to 8.5.8+ and
> need
> to clarify some possible inconsistencies for new/changed roles "*" and "**"
> from Servlet 3.1, section 13 how Tomcat implements this behavior.
>
> org.apache.catalina.connector.Request#isUserInRole(String) properly handles
> "*"
> (this has changed) and "**" according to the spec. It handles it off to
> Realm#hasRole(). RealmBase delegates this decision to
> GenericPrincipal#hasRole(String) but this likely violates the spec in my
> opinion by
>> if ("*".equals(role)) {// Special 2.4 role meaning everyone
>> return true;
>> }
> as well as the UserDatabaseRealm#hasRole(Wrapper, Principal, String):
>> if("*".equals(role)) {
>> return true;
>> }
>
> Since we are using a custom realm and principal, my questions are:
>
> 1. According to the specs, "*" should never be passed to the request or
> principal.
> It should rather be handled by the container checking whether the user has
> any
> of the declared roles and match in that case. Are GenericPrincipal and
> UserDatabaseRealm violating these specs?
Yes. They also ignore "**" and RealmBase.allRolesMode
I'd consider removing RealmBase.allRolesMode for 9.0.x onwards.
Mark
> It should be as little as:
> public boolean hasRole(String role) {
> return Arrays.binarySearch(roles, role) >= 0;
> }
> Null check and else is done by the realm already.
> 2. How should CustomPrincipal#hasRole(String) and
> CustomRealm#hasRole(Wrapper, Principal, String)
> look like to satisfy the behavior without breaking the specs?
> It is currently a mere copy and paste from GenericPrincipal#hasRole()
> and RealmBase#hasRole() in our code.
>
> Best regards,
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
