tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Nondeterministic behaviour of security constraints in Tomcat 7
Date Wed, 29 Aug 2012 18:06:21 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matteo,

On 8/29/12 11:24 AM, CASALINO, Matteo Maria wrote:
> Hello everyone,
> 
> I'm experiencing a weird behaviour with certain combinations of
> security constraints having the following pattern: (i) one security
> constraint applies to (at least) two overlapping URL patterns
> ending in /*, where one is more specific than the other (e.g., /a/*
> and /a/b/*) (ii) a second security constraint applies only to the
> less specific URL pattern (e.g. /a/*), and (iii) the two security
> constraints apply to different (possibly overlapping) sets of
> methods.
> 
> One such example is as follows:
> 
> <servlet-mapping> <servlet-name>test</servlet-name> 
> <url-pattern>/*</url-pattern> </servlet-mapping> <login-config>

> <auth-method>BASIC</auth-method> <realm-name>test</realm-name>

> </login-config>
> 
> <security-constraint> <web-resource-collection> 
> <web-resource-name/> <url-pattern>/a/*</url-pattern> 
> <url-pattern>/a/b/*</url-pattern> <http-method>POST</http-method>

> </web-resource-collection> </security-constraint>
> 
> <security-constraint> <web-resource-collection> 
> <web-resource-name/> <url-pattern>/a/*</url-pattern> 
> <http-method>GET</http-method> </web-resource-collection> 
> <auth-constraint/> </security-constraint>
> 
> The problem occurs for HTTP requests matching to the most specific
> URL pattern (in the above example, /a/b, /a/b/c, etc.), but on
> methods other than the ones mentioned in the first security
> constraint (in the above example, GET).
> 
> For instance, each time I deploy a web application with the
> above-mentioned deployment descriptor in Tomcat, or each time I
> redeploy it or restart the server in case it is already deployed, I
> get randomly either of the two following behaviours:
> 
> 1) "GET /a/b" requests are allowed, i.e. no authentication is
> required 2) "GET /a/b" requests are denied, i.e. the response
> requires authentication (HTTP 401)
> 
> Notice that the behaviour remains then constant until I restart the
> server or re-deploy the application. Also, adding arbitrary roles
> in either of the two auth-constraints, does not seem to change the
> result.
> 
> According to the Java Servlet Specification, 1) is the correct
> behaviour. In fact, such requests shall be allowed to any (possibly
> unauthenticated) users, because the constraint with the most
> specific pattern (the first one) matches to the request, but it
> does not mention the method of the request (GET).
> 
> I tested several different combinations of security constraints,
> but this issue seems to occur only with those of this kind. Tests
> were done on Tomcat 7.0.29 running on both a Debian and a Windows
> machine.
> 
> 
> Have anyone experienced a similar problem or is aware of possible
> explanations?

Would it be possible for you to set up a simple test case and package
it as a WAR? Also, write-up a set of URLs and your expectations about
whether they should work or not and attach all that to a Bugzilla report:
https://issues.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%207

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlA+Wh0ACgkQ9CaO5/Lv0PAMKACgsDluZYIQAkebPrCFlJbCpfDE
musAoIM15SWO2FdkWeeWBZQC1FQlA63J
=VJM6
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message