You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Osipov, Michael" <mi...@siemens.com> on 2016/11/21 10:45:51 UTC
Clarification on roles "*" and "**" in Tomcat 8.5.x
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?
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Clarification on roles "*" and "**" in Tomcat 8.5.x
Posted by "Osipov, Michael" <mi...@siemens.com>.
> 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.
Thanks! It that worth creating two issues?
Additionally, it somewhat implies an answer to my second question:
Roles should be treated as-is.
Regards,
Michael
> > 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Clarification on roles "*" and "**" in Tomcat 8.5.x
Posted by Mark Thomas <ma...@apache.org>.
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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org