RE: Nondeterministic behaviour of security constraints in Tomcat 7
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 Sure, I will do so. The issue is actually due to a bug [1] in the initialization of some data structure holding security constraints. It has already been fixed in trunk and the fix will be part of 7.0.30. --Matteo [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=53801
RE: Nondeterministic behaviour of security constraints in Tomcat 7
-Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: mercredi 29 août 2012 22:34 To: Tomcat Users List Subject: RE: Nondeterministic behaviour of security constraints in Tomcat 7 The problem occurs for HTTP requests matching to the most specific URL pattern (in the above example, /a/b, /a/b/c, etc.), Please state where in the servlet spec that /a/b should be matched by /a/b/*. (If the request for /a/b were to be redirected to /a/b/, that would be matched.) According to §13.8.3 of the spec [1]: When a Servlet container receives a request, it shall use the algorithm described in Use of URL Paths on page 115 to select the constraints (if any) defined on the urlpattern that is the best match to the request URI I agree that in the algorithm it is not explicitly stated that /a/b should match to /a/b/*, however §12.2.2 provides an example which, in my eyes, does so: TABLE 12-1 Example Set of Maps --- Path Pattern Servlet /foo/bar/* servlet1 /baz/* servlet2 /catalog servlet3 *.bopservlet4 TABLE 12-2 Incoming Paths Applied to Example Maps -- Incoming Path Servlet Handling Request /foo/bar/index.htmlservlet1 /foo/bar/index.bop servlet1 /baz servlet2 /baz/index.htmlservlet2 You might want to add /a/b as an explicit url- pattern to avoid having requests to that target being handled by the /a/* rule. The same behaviour I described is verified as well for every other request that matches /a/b/*, such as /a/b/, /a/b/c, and so on. Best regards, Matteo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Nondeterministic behaviour of security constraints in Tomcat 7
Dear Chris, -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: mercredi 29 août 2012 20:06 To: Tomcat Users List Subject: Re: Nondeterministic behaviour of security constraints in Tomcat 7 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 Sure, I will do so. Regards, Matteo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Nondeterministic behaviour of security constraints in Tomcat 7
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-nametest/servlet-name url-pattern/*/url-pattern /servlet-mapping login-config auth-methodBASIC/auth-method realm-nametest/realm-name /login-config security-constraint web-resource-collection web-resource-name/ url-pattern/a/*/url-pattern url-pattern/a/b/*/url-pattern http-methodPOST/http-method /web-resource-collection /security-constraint security-constraint web-resource-collection web-resource-name/ url-pattern/a/*/url-pattern http-methodGET/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? Best regards, Matteo Casalino Research Associate Security Trust SAP Research, SAP Labs France SAS - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
