JACC URLPatternSpec does not accept *do:login.do as it should
-------------------------------------------------------------
Key: GERONIMO-2763
URL: https://issues.apache.org/jira/browse/GERONIMO-2763
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: security, specs
Affects Versions: 2.0-M1, 1.1.1
Reporter: David Jencks
Assigned To: David Jencks
Fix For: 2.0-M2
This problem was originally reported by Dmitry Colebach in GERONIMO-1585. I've
copied his description here:
I'd like to add some related thoughts to this:
I have the following in my web.xml:
<security-constraint>
<web-resource-collection>
<web-resource-name>Struts pages</web-resource-name>
<url-pattern>*.do</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Login page</web-resource-name>
<url-pattern>/login.do</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
</security-constraint>
So the outcome I want is that in general struts pages require
authentication, but the login page doesn't require authentication
(obviously). This has been working fine on WL but when I try to
deploy on Geronimo I get this:
Caused by: java.lang.IllegalArgumentException: Only exact and
path-prefix qualifiers in the URLPatternSpec are allowed when first
URLPattern is an extension pattern
at javax.security.jacc.URLPatternSpec.<init>(URLPatternSpec.java:82)
at
javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:54)
at
org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.buildSpecSecurityConfig(AbstractWebModuleBuilder.java:357)
Debugging through the code, AbstractWebModuleBuilder is merging all
the patterns including ones that don't require authentication and so
is trying to create a WebResourcePermission instance with the string
"*.do:/login.do".
The servlet spec section "12.8.1 Combining constraints" says:
"A security constraint that does not contain an authorization
constraint shall combine with authorization constraints that name or
imply roles to allow unauthenticated access."
I realise this isn't exactly what this bug is about, but it should be addressed
at the same time.
[ Show ยป ]
Dmitri Colebatch [21/Sep/06 05:43 PM] I'd like to add some related thoughts to
this: I have the following in my web.xml: <security-constraint>
<web-resource-collection> <web-resource-name>Struts pages</web-resource-name>
<url-pattern>*.do</url-pattern> <http-method>GET</http-method>
<http-method>POST</http-method> </web-resource-collection> <auth-constraint>
<role-name>*</role-name> </auth-constraint> </security-constraint>
<security-constraint> <web-resource-collection> <web-resource-name>Login
page</web-resource-name> <url-pattern>/login.do</url-pattern>
<http-method>GET</http-method> </web-resource-collection>
</security-constraint> So the outcome I want is that in general struts pages
require authentication, but the login page doesn't require authentication
(obviously). This has been working fine on WL but when I try to deploy on
Geronimo I get this: Caused by: java.lang.IllegalArgumentException: Only exact
and path-prefix qualifiers in the URLPatternSpec are allowed when first
URLPattern is an extension pattern at
javax.security.jacc.URLPatternSpec.<init>(URLPatternSpec.java:82) at
javax.security.jacc.WebResourcePermission.<init>(WebResourcePermission.java:54)
at
org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.buildSpecSecurityConfig(AbstractWebModuleBuilder.java:357)
Debugging through the code, AbstractWebModuleBuilder is merging all the
patterns including ones that don't require authentication and so is trying to
create a WebResourcePermission instance with the string "*.do:/login.do". The
servlet spec section "12.8.1 Combining constraints" says: "A security
constraint that does not contain an authorization constraint shall combine with
authorization constraints that name or imply roles to allow unauthenticated
access." I realise this isn't exactly what this bug is about, but it should be
addressed at the same time.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
