You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by lu...@apache.org on 2005/03/02 20:27:11 UTC
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
luehe 2005/03/02 11:27:11
Modified: catalina/src/share/org/apache/catalina/realm RealmBase.java
Log:
Consider the case where original request was mapped to welcome page.
In this case, the mapped welcome page (and not the original request
URI!) needs to be the target of hasResourcePermission().
This is consistent with the change that had been made in findSecurityConstraints().
BTW, shouldn't request.getDecodedRequestURI() return the mapped
welcome page (instead of the original URI) in this case?
In other words, shouldn't the path passed to
mappingData.requestPath.setString(pathStr)
in Mapper.java be propagated to the request object associatd with the
mappingData?
Revision Changes Path
1.49 +2 -2 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java
Index: RealmBase.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- RealmBase.java 23 Feb 2005 19:27:56 -0000 1.48
+++ RealmBase.java 2 Mar 2005 19:27:11 -0000 1.49
@@ -702,7 +702,7 @@
LoginConfig config = context.getLoginConfig();
if ((config != null) &&
(Constants.FORM_METHOD.equals(config.getAuthMethod()))) {
- String requestURI = request.getDecodedRequestURI();
+ String requestURI = request.getRequestPathMB().toString();
String loginPage = context.getPath() + config.getLoginPage();
if (loginPage.equals(requestURI)) {
if (log.isDebugEnabled())
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
RealmBase.java
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> Remy,
>
> Remy Maucherat wrote:
>
>>Jan Luehe wrote:
>>
>>>Bill/Remy,
>>>
>>>But SRV.9.10 ("Welcome Files") already has this:
>>>
>>> The container may send the request to the welcome resource with
>>> a forward, a redirect, or a container specific mechanism
>>> **that is indistinguishable from a direct request**.
>>>
>>>The latter to me implies that any sec constraints must be applied
>>>to the mapped welcome page (if any).
>>
>>The plot thickens.
>
> What do you mean by that? ;-)
> Do you agree the spec is pretty clear about the fact that
> any sec constraints must be applied to welcome page?
It means that the statement would seem to be conflicting with other
things, but still seems relevant to the topic. So it makes the problem
more complex.
>>Right. However, when I made that commit, the current mapper behavior may
>>not have been in place already, or maybe it's simply that I thought the
>>two would be equivalent (I was busy optimizing at the time). I don't
>>quite remember ;)
>
> I think you did the right thing without realizing it. :)
> The change I committed earlier today is just consistent with
> what you had done.
I was out to kiil the substring thing.
> I'm still nervous about request.getDecodedRequestURI() returning
> the original URI even after the request has been mapped to a welcome
> page. This violates spec requirement that any container specific
> mechanism for mapping request to welcome page must be
> "indistinguishable from a direct request".
Changing this is very risky, as it will have uses elsewhere. If using
Eclipse, you should use the call hierarchy (since it's an internal
method which is never used through reflection).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
RealmBase.java
Posted by Jan Luehe <Ja...@Sun.COM>.
Remy,
Remy Maucherat wrote:
> Jan Luehe wrote:
>
>>Bill/Remy,
>>
>>But SRV.9.10 ("Welcome Files") already has this:
>>
>> The container may send the request to the welcome resource with
>> a forward, a redirect, or a container specific mechanism
>> **that is indistinguishable from a direct request**.
>>
>>The latter to me implies that any sec constraints must be applied
>>to the mapped welcome page (if any).
>
>
> The plot thickens.
What do you mean by that? ;-)
Do you agree the spec is pretty clear about the fact that
any sec constraints must be applied to welcome page?
>>Also, see the attached diffs, in particular:
>>
>>- String uri = request.getDecodedRequestURI();
>>- String contextPath = hreq.getContextPath();
>>- if (contextPath.length() > 0)
>>- uri = uri.substring(contextPath.length());
>>+ String uri = request.getRequestPathMB().toString();
>>
>>in findSecurityConstraints().
>>
>>When accessing <host>:<port>:/somecontext/,
>>which has welcome page /somecontext/index.jsp,
>>
>>request.getDecodedRequestURI() returns "/somecontext/",
>>whereas request.getRequestPathMB().toString() returns
>>"/index.jsp" (as set by the mapper), so there already is a precedent
>>in findSecurityConstraints() to match sec constraints against
>>welcome page, which I think makes sense.
>
>
> Right. However, when I made that commit, the current mapper behavior may
> not have been in place already, or maybe it's simply that I thought the
> two would be equivalent (I was busy optimizing at the time). I don't
> quite remember ;)
I think you did the right thing without realizing it. :)
The change I committed earlier today is just consistent with
what you had done.
I'm still nervous about request.getDecodedRequestURI() returning
the original URI even after the request has been mapped to a welcome
page. This violates spec requirement that any container specific
mechanism for mapping request to welcome page must be
"indistinguishable from a direct request".
Jan
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
RealmBase.java
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> Bill/Remy,
>
> But SRV.9.10 ("Welcome Files") already has this:
>
> The container may send the request to the welcome resource with
> a forward, a redirect, or a container specific mechanism
> **that is indistinguishable from a direct request**.
>
> The latter to me implies that any sec constraints must be applied
> to the mapped welcome page (if any).
The plot thickens.
> Also, see the attached diffs, in particular:
>
> - String uri = request.getDecodedRequestURI();
> - String contextPath = hreq.getContextPath();
> - if (contextPath.length() > 0)
> - uri = uri.substring(contextPath.length());
> + String uri = request.getRequestPathMB().toString();
>
> in findSecurityConstraints().
>
> When accessing <host>:<port>:/somecontext/,
> which has welcome page /somecontext/index.jsp,
>
> request.getDecodedRequestURI() returns "/somecontext/",
> whereas request.getRequestPathMB().toString() returns
> "/index.jsp" (as set by the mapper), so there already is a precedent
> in findSecurityConstraints() to match sec constraints against
> welcome page, which I think makes sense.
Right. However, when I made that commit, the current mapper behavior may
not have been in place already, or maybe it's simply that I thought the
two would be equivalent (I was busy optimizing at the time). I don't
quite remember ;)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
RealmBase.java
Posted by Jan Luehe <Ja...@Sun.COM>.
Bill,
Bill Barker wrote:
> ----- Original Message -----
> From: "Jan Luehe" <Ja...@Sun.COM>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Wednesday, March 02, 2005 12:51 PM
> Subject: Re: cvs commit:
> jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
> RealmBase.java
>
>
>
>>Bill/Remy,
>>
>>Bill Barker wrote:
>>
>>>----- Original Message -----
>>>From: "Remy Maucherat" <re...@apache.org>
>>>To: "Tomcat Developers List" <to...@jakarta.apache.org>
>>>Sent: Wednesday, March 02, 2005 11:56 AM
>>>Subject: Re: cvs commit:
>>>jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
>>>RealmBase.java
>>>
>>>
>>>
>>>
>>>>luehe@apache.org wrote:
>>>>
>>>>
>>>>>luehe 2005/03/02 11:27:11
>>>>>
>>>>> Modified: catalina/src/share/org/apache/catalina/realm
>>>
>>>RealmBase.java
>>>
>>>
>>>>> Log:
>>>>> Consider the case where original request was mapped to welcome page.
>>>>> In this case, the mapped welcome page (and not the original request
>>>>> URI!) needs to be the target of hasResourcePermission().
>>>>>
>>>>> This is consistent with the change that had been made in
>>>
>>>findSecurityConstraints().
>>>
>>>
>>>>> BTW, shouldn't request.getDecodedRequestURI() return the mapped
>>>>> welcome page (instead of the original URI) in this case?
>>>>> In other words, shouldn't the path passed to
>>>>> mappingData.requestPath.setString(pathStr)
>>>>> in Mapper.java be propagated to the request object associatd with the
>>>>> mappingData?
>>>>
>>>>I consider welcome files to be internal forwards (since it is allowed to
>>>>handle them this way). As a result, they shouldn't be matched by
>>>>secrurity constraints. Only the original request path should be the used
>>>>(so here it's getDecodedRequestURI - as sent by the client).
>>>>
>>>
>>>
>>>I agree with Remy. It's an internal Tomcat implementation detail that
>>>welcome-files aren't handled via DefaultServlet doing:
>>> RequestDispatcher rd = request.getRequestDispatcher(welcome[i]);
>>> rd.forward(request, response);
>>>Since this is explicitly allowed by the spec, nobody can expect that a
>>>security-constraint mapped only to the welcome-file will be applied.
>>>However, this is probably another thing that should be better specified
>
> in
>
>>>the 2.5 spec.
>>
>>
>>But SRV.9.10 ("Welcome Files") already has this:
>>
>> The container may send the request to the welcome resource with
>> a forward, a redirect, or a container specific mechanism
>> **that is indistinguishable from a direct request**.
>>
>
>
> I read the emphasised text as referring to 'container specific mechanism'.
So do I. "indistinguishable from a direct request" means that any
sec constraints will have to be applied to welcome pages when the
request is sent to the welcome page via container specific
mechanism (as in Tomcat).
> Yes, I agree that the last-minute changes that were made to 9.10 made it a
> total mess, but it still explicitly allows DefaultServlet to do a
> rd.forward.
Yes, in which case the welcome page that is the target of the
rd.forward() will not be subjected to any sec constraints.
So the spec is inconsistent as to whether sec constraints need to
be applied to welcome pages.
This means that web developers should always use a pattern of this
form:
<url-pattern>/*</url-pattern>
in their DD's security constraints if they want their welcome
pages to be subjected to the specified sec constraints no matter
which container their webapp is deployed on.
If they specify:
<url-pattern>*.jsp</url-pattern>
their index.jsp welcome page will not be subjected to any sec
constraints in containers that send the request to the welcome page
using rd.forward().
>>The latter to me implies that any sec constraints must be applied
>>to the mapped welcome page (if any).
>>
>>Also, see the attached diffs, in particular:
>>
>
>
> Firstly, I'm strongly -1 on the patch, since removing the 'if(found)return'
> statements causes Tomcat to no longer be spec-complient. Just because the
> spec is silly doesn't mean that we don't have to implement it.
The patch I attached has been 1 year old.
My main purpose in attaching it was to draw attention to
this change in rev 1.24:
>
>
>>- String uri = request.getDecodedRequestURI();
>>- String contextPath = hreq.getContextPath();
>>- if (contextPath.length() > 0)
>>- uri = uri.substring(contextPath.length());
>>+ String uri = request.getRequestPathMB().toString();
>>
>>in findSecurityConstraints().
Remy had restored the 'if(found)return' in rev 1.25:
revision 1.25
date: 2004/01/11 09:23:42; author: remm; state: Exp; lines: +11 -11
- Ooops. Put back the if(found) blocks.
----------------------------
revision 1.24
date: 2004/01/10 17:23:39; author: remm; state: Exp; lines: +16 -11
- findMethod wasn't called on the right collection.
- The algorithm ignored extension mapped constraints as long as a widcard
or exact mapped constraint was found. This doesn't seem right (I did
quickly
read the relevant portions of the spec).
- Next, I'll try to optimize the algorithm (allocating a collection on
each request
is not good, we should add a matched contraints array on the request).
>>When accessing <host>:<port>:/somecontext/,
>>which has welcome page /somecontext/index.jsp,
>>
>>request.getDecodedRequestURI() returns "/somecontext/",
>>whereas request.getRequestPathMB().toString() returns
>>"/index.jsp" (as set by the mapper), so there already is a precedent
>>in findSecurityConstraints() to match sec constraints against
>>welcome page, which I think makes sense.
>>
>
>
> Servlet 12.8.3 says to use the decoded requestURI, which is defined as
> contextPath+servletPath+pathInfo. Since servletPath is set to /index.jsp in
> Tomcat, I guess that requestPathMB is the correct one to use.
yes, I agree, but also notice that when using
request.getDecodedRequestURI(), you get the original URI (e.g.,
"/somecontext/"), from which "/" is left after removing the contextPath
prefix, and "/" matches only those sec constraints with a URL pattern
of "/*".
A side effect of using request.getRequestPathMB().toString() is that
we get the servletPath of the mapped welcome page ("/index.jsp"),
which is what we want in order for the sec constraints to be
applied to the mapped welcome page.
My commit earlier this morning made corresponding change
to RealmBase.hasResourcePermission(), i.e., it replaced
String uri = request.getDecodedRequestURI();
with
String uri = request.getRequestPathMB().toString();
Jan
>
>>Otherwise, the following sec constraint:
>>
>> <security-constraint>
>> <web-resource-collection>
>> <web-resource-name>Protected Area</web-resource-name>
>> <url-pattern>*.jsp</url-pattern>
>> <http-method>PUT</http-method>
>> <http-method>DELETE</http-method>
>> <http-method>GET</http-method>
>> <http-method>POST</http-method>
>> </web-resource-collection>
>> <auth-constraint>
>> <role-name>tomcat</role-name>
>> </auth-constraint>
>> </security-constraint>
>>
>>which is supposed to protect all JSP pages, would be bypassed if a
>>request was mapped to index.jsp welcome page.
>>
>>
>>Jan
>>
>
>
>
>>>Rémy
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>
>>This message is intended only for the use of the person(s) listed above as
>
> the intended recipient(s), and may contain information that is PRIVILEGED
> and CONFIDENTIAL. If you are not an intended recipient, you may not read,
> copy, or distribute this message or any attachment. If you received this
> communication in error, please notify us immediately by e-mail and then
> delete all copies of this message and any attachments.
>
>>In addition you should be aware that ordinary (unencrypted) e-mail sent
>
> through the Internet is not secure. Do not send confidential or sensitive
> information, such as social security numbers, account numbers, personal
> identification numbers and passwords, to us via ordinary (unencrypted)
> e-mail.
>
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>
> ----------------------------------------------------------------------------
> ----
>
>
>
>>Index: RealmBase.java
>>===================================================================
>>RCS file:
>
> /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/rea
> lm/RealmBase.java,v
>
>>retrieving revision 1.23
>>retrieving revision 1.24
>>diff -u -r1.23 -r1.24
>>--- RealmBase.java 26 Dec 2003 17:33:44 -0000 1.23
>>+++ RealmBase.java 10 Jan 2004 17:23:39 -0000 1.24
>>@@ -1,7 +1,7 @@
>> /*
>>- * $Header:
>
> /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/rea
> lm/RealmBase.java,v 1.23 2003/12/26 17:33:44 remm Exp $
>
>>- * $Revision: 1.23 $
>>- * $Date: 2003/12/26 17:33:44 $
>>+ * $Header:
>
> /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/rea
> lm/RealmBase.java,v 1.24 2004/01/10 17:23:39 remm Exp $
>
>>+ * $Revision: 1.24 $
>>+ * $Date: 2004/01/10 17:23:39 $
>> *
>> * ====================================================================
>> *
>>@@ -107,7 +107,7 @@
>> * location) are identical to those currently supported by Tomcat 3.X.
>> *
>> * @author Craig R. McClanahan
>>- * @version $Revision: 1.23 $ $Date: 2003/12/26 17:33:44 $
>>+ * @version $Revision: 1.24 $ $Date: 2004/01/10 17:23:39 $
>> */
>>
>> public abstract class RealmBase
>>@@ -457,10 +457,7 @@
>>
>> // Check each defined security constraint
>> HttpServletRequest hreq = (HttpServletRequest)
>
> request.getRequest();
>
>>- String uri = request.getDecodedRequestURI();
>>- String contextPath = hreq.getContextPath();
>>- if (contextPath.length() > 0)
>>- uri = uri.substring(contextPath.length());
>>+ String uri = request.getRequestPathMB().toString();
>>
>> String method = hreq.getMethod();
>> int i;
>>@@ -486,10 +483,12 @@
>> }
>> }
>> }
>>- }
>>+ }
>>+ /*
>> if(found) {
>> return resultsToArray(results);
>> }
>>+ */
>> int longest = -1;
>>
>> for (i = 0; i < constraints.length; i++) {
>>@@ -535,9 +534,11 @@
>> }
>> }
>> }
>>+ /*
>> if(found) {
>> return resultsToArray(results);
>> }
>>+ */
>> for (i = 0; i < constraints.length; i++) {
>> SecurityCollection [] collection =
>
> constraints[i].findCollections();
>
>>@@ -546,6 +547,7 @@
>> "' against " + method + " " + uri + " --> " +
>> constraints[i].included(uri, method));
>> boolean matched = false;
>>+ int pos = -1;
>> for(int j=0; j < collection.length; j++){
>> String [] patterns = collection[j].findPatterns();
>> for(int k=0; k < patterns.length && !matched; k++) {
>>@@ -558,6 +560,7 @@
>> uri.length()-dot == pattern.length()-1) {
>>
>
> if(pattern.regionMatches(1,uri,dot,uri.length()-dot)) {
>
>> matched = true;
>>+ pos = j;
>> }
>> }
>> }
>>@@ -565,17 +568,19 @@
>> }
>> if(matched) {
>> found = true;
>>- if(collection[i].findMethod(method)) {
>>+ if(collection[pos].findMethod(method)) {
>> if(results == null) {
>> results = new ArrayList();
>>- }
>>+ }
>> results.add(constraints[i]);
>> }
>> }
>> }
>>+ /*
>> if(found) {
>> return resultsToArray(results);
>> }
>>+ */
>> for (i = 0; i < constraints.length; i++) {
>> SecurityCollection [] collection =
>
> constraints[i].findCollections();
>
>>
>>
>
>
> ----------------------------------------------------------------------------
> ----
>
>
>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>
> This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jan Luehe" <Ja...@Sun.COM>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, March 02, 2005 12:51 PM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
RealmBase.java
>Bill/Remy,
>
>Bill Barker wrote:
>> ----- Original Message -----
>> From: "Remy Maucherat" <re...@apache.org>
>> To: "Tomcat Developers List" <to...@jakarta.apache.org>
>> Sent: Wednesday, March 02, 2005 11:56 AM
>> Subject: Re: cvs commit:
>> jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
>> RealmBase.java
>>
>>
>>
>>>luehe@apache.org wrote:
>>>
>>>>luehe 2005/03/02 11:27:11
>>>>
>>>> Modified: catalina/src/share/org/apache/catalina/realm
>>
>> RealmBase.java
>>
>>>> Log:
>>>> Consider the case where original request was mapped to welcome page.
>>>> In this case, the mapped welcome page (and not the original request
>>>> URI!) needs to be the target of hasResourcePermission().
>>>>
>>>> This is consistent with the change that had been made in
>>
>> findSecurityConstraints().
>>
>>>> BTW, shouldn't request.getDecodedRequestURI() return the mapped
>>>> welcome page (instead of the original URI) in this case?
>>>> In other words, shouldn't the path passed to
>>>> mappingData.requestPath.setString(pathStr)
>>>> in Mapper.java be propagated to the request object associatd with the
>>>> mappingData?
>>>
>>>I consider welcome files to be internal forwards (since it is allowed to
>>>handle them this way). As a result, they shouldn't be matched by
>>>secrurity constraints. Only the original request path should be the used
>>>(so here it's getDecodedRequestURI - as sent by the client).
>>>
>>
>>
>> I agree with Remy. It's an internal Tomcat implementation detail that
>> welcome-files aren't handled via DefaultServlet doing:
>> RequestDispatcher rd = request.getRequestDispatcher(welcome[i]);
>> rd.forward(request, response);
>> Since this is explicitly allowed by the spec, nobody can expect that a
>> security-constraint mapped only to the welcome-file will be applied.
>> However, this is probably another thing that should be better specified
in
>> the 2.5 spec.
>
>
>But SRV.9.10 ("Welcome Files") already has this:
>
> The container may send the request to the welcome resource with
> a forward, a redirect, or a container specific mechanism
> **that is indistinguishable from a direct request**.
>
I read the emphasised text as referring to 'container specific mechanism'.
Yes, I agree that the last-minute changes that were made to 9.10 made it a
total mess, but it still explicitly allows DefaultServlet to do a
rd.forward.
>The latter to me implies that any sec constraints must be applied
>to the mapped welcome page (if any).
>
>Also, see the attached diffs, in particular:
>
Firstly, I'm strongly -1 on the patch, since removing the 'if(found)return'
statements causes Tomcat to no longer be spec-complient. Just because the
spec is silly doesn't mean that we don't have to implement it.
>- String uri = request.getDecodedRequestURI();
>- String contextPath = hreq.getContextPath();
>- if (contextPath.length() > 0)
>- uri = uri.substring(contextPath.length());
>+ String uri = request.getRequestPathMB().toString();
>
>in findSecurityConstraints().
>
>When accessing <host>:<port>:/somecontext/,
>which has welcome page /somecontext/index.jsp,
>
>request.getDecodedRequestURI() returns "/somecontext/",
>whereas request.getRequestPathMB().toString() returns
>"/index.jsp" (as set by the mapper), so there already is a precedent
>in findSecurityConstraints() to match sec constraints against
>welcome page, which I think makes sense.
>
Servlet 12.8.3 says to use the decoded requestURI, which is defined as
contextPath+servletPath+pathInfo. Since servletPath is set to /index.jsp in
Tomcat, I guess that requestPathMB is the correct one to use.
>Otherwise, the following sec constraint:
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Protected Area</web-resource-name>
> <url-pattern>*.jsp</url-pattern>
> <http-method>PUT</http-method>
> <http-method>DELETE</http-method>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> <auth-constraint>
> <role-name>tomcat</role-name>
> </auth-constraint>
> </security-constraint>
>
>which is supposed to protect all JSP pages, would be bypassed if a
>request was mapped to index.jsp welcome page.
>
>
>Jan
>
>
>>Rémy
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>
>
> This message is intended only for the use of the person(s) listed above as
the intended recipient(s), and may contain information that is PRIVILEGED
and CONFIDENTIAL. If you are not an intended recipient, you may not read,
copy, or distribute this message or any attachment. If you received this
communication in error, please notify us immediately by e-mail and then
delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
----------------------------------------------------------------------------
----
> Index: RealmBase.java
> ===================================================================
> RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/rea
lm/RealmBase.java,v
> retrieving revision 1.23
> retrieving revision 1.24
> diff -u -r1.23 -r1.24
> --- RealmBase.java 26 Dec 2003 17:33:44 -0000 1.23
> +++ RealmBase.java 10 Jan 2004 17:23:39 -0000 1.24
> @@ -1,7 +1,7 @@
> /*
> - * $Header:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/rea
lm/RealmBase.java,v 1.23 2003/12/26 17:33:44 remm Exp $
> - * $Revision: 1.23 $
> - * $Date: 2003/12/26 17:33:44 $
> + * $Header:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/rea
lm/RealmBase.java,v 1.24 2004/01/10 17:23:39 remm Exp $
> + * $Revision: 1.24 $
> + * $Date: 2004/01/10 17:23:39 $
> *
> * ====================================================================
> *
> @@ -107,7 +107,7 @@
> * location) are identical to those currently supported by Tomcat 3.X.
> *
> * @author Craig R. McClanahan
> - * @version $Revision: 1.23 $ $Date: 2003/12/26 17:33:44 $
> + * @version $Revision: 1.24 $ $Date: 2004/01/10 17:23:39 $
> */
>
> public abstract class RealmBase
> @@ -457,10 +457,7 @@
>
> // Check each defined security constraint
> HttpServletRequest hreq = (HttpServletRequest)
request.getRequest();
> - String uri = request.getDecodedRequestURI();
> - String contextPath = hreq.getContextPath();
> - if (contextPath.length() > 0)
> - uri = uri.substring(contextPath.length());
> + String uri = request.getRequestPathMB().toString();
>
> String method = hreq.getMethod();
> int i;
> @@ -486,10 +483,12 @@
> }
> }
> }
> - }
> + }
> + /*
> if(found) {
> return resultsToArray(results);
> }
> + */
> int longest = -1;
>
> for (i = 0; i < constraints.length; i++) {
> @@ -535,9 +534,11 @@
> }
> }
> }
> + /*
> if(found) {
> return resultsToArray(results);
> }
> + */
> for (i = 0; i < constraints.length; i++) {
> SecurityCollection [] collection =
constraints[i].findCollections();
>
> @@ -546,6 +547,7 @@
> "' against " + method + " " + uri + " --> " +
> constraints[i].included(uri, method));
> boolean matched = false;
> + int pos = -1;
> for(int j=0; j < collection.length; j++){
> String [] patterns = collection[j].findPatterns();
> for(int k=0; k < patterns.length && !matched; k++) {
> @@ -558,6 +560,7 @@
> uri.length()-dot == pattern.length()-1) {
>
if(pattern.regionMatches(1,uri,dot,uri.length()-dot)) {
> matched = true;
> + pos = j;
> }
> }
> }
> @@ -565,17 +568,19 @@
> }
> if(matched) {
> found = true;
> - if(collection[i].findMethod(method)) {
> + if(collection[pos].findMethod(method)) {
> if(results == null) {
> results = new ArrayList();
> - }
> + }
> results.add(constraints[i]);
> }
> }
> }
> + /*
> if(found) {
> return resultsToArray(results);
> }
> + */
> for (i = 0; i < constraints.length; i++) {
> SecurityCollection [] collection =
constraints[i].findCollections();
>
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
RealmBase.java
Posted by Jan Luehe <Ja...@Sun.COM>.
Bill/Remy,
Bill Barker wrote:
> ----- Original Message -----
> From: "Remy Maucherat" <re...@apache.org>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Wednesday, March 02, 2005 11:56 AM
> Subject: Re: cvs commit:
> jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
> RealmBase.java
>
>
>
>>luehe@apache.org wrote:
>>
>>>luehe 2005/03/02 11:27:11
>>>
>>> Modified: catalina/src/share/org/apache/catalina/realm
>
> RealmBase.java
>
>>> Log:
>>> Consider the case where original request was mapped to welcome page.
>>> In this case, the mapped welcome page (and not the original request
>>> URI!) needs to be the target of hasResourcePermission().
>>>
>>> This is consistent with the change that had been made in
>
> findSecurityConstraints().
>
>>> BTW, shouldn't request.getDecodedRequestURI() return the mapped
>>> welcome page (instead of the original URI) in this case?
>>> In other words, shouldn't the path passed to
>>> mappingData.requestPath.setString(pathStr)
>>> in Mapper.java be propagated to the request object associatd with the
>>> mappingData?
>>
>>I consider welcome files to be internal forwards (since it is allowed to
>>handle them this way). As a result, they shouldn't be matched by
>>secrurity constraints. Only the original request path should be the used
>>(so here it's getDecodedRequestURI - as sent by the client).
>>
>
>
> I agree with Remy. It's an internal Tomcat implementation detail that
> welcome-files aren't handled via DefaultServlet doing:
> RequestDispatcher rd = request.getRequestDispatcher(welcome[i]);
> rd.forward(request, response);
> Since this is explicitly allowed by the spec, nobody can expect that a
> security-constraint mapped only to the welcome-file will be applied.
> However, this is probably another thing that should be better specified in
> the 2.5 spec.
But SRV.9.10 ("Welcome Files") already has this:
The container may send the request to the welcome resource with
a forward, a redirect, or a container specific mechanism
**that is indistinguishable from a direct request**.
The latter to me implies that any sec constraints must be applied
to the mapped welcome page (if any).
Also, see the attached diffs, in particular:
- String uri = request.getDecodedRequestURI();
- String contextPath = hreq.getContextPath();
- if (contextPath.length() > 0)
- uri = uri.substring(contextPath.length());
+ String uri = request.getRequestPathMB().toString();
in findSecurityConstraints().
When accessing <host>:<port>:/somecontext/,
which has welcome page /somecontext/index.jsp,
request.getDecodedRequestURI() returns "/somecontext/",
whereas request.getRequestPathMB().toString() returns
"/index.jsp" (as set by the mapper), so there already is a precedent
in findSecurityConstraints() to match sec constraints against
welcome page, which I think makes sense.
Otherwise, the following sec constraint:
<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>*.jsp</url-pattern>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>tomcat</role-name>
</auth-constraint>
</security-constraint>
which is supposed to protect all JSP pages, would be bypassed if a
request was mapped to index.jsp welcome page.
Jan
>
>>Rémy
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>
>
> This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, March 02, 2005 11:56 AM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
RealmBase.java
>luehe@apache.org wrote:
>> luehe 2005/03/02 11:27:11
>>
>> Modified: catalina/src/share/org/apache/catalina/realm
RealmBase.java
>> Log:
>> Consider the case where original request was mapped to welcome page.
>> In this case, the mapped welcome page (and not the original request
>> URI!) needs to be the target of hasResourcePermission().
>>
>> This is consistent with the change that had been made in
findSecurityConstraints().
>>
>> BTW, shouldn't request.getDecodedRequestURI() return the mapped
>> welcome page (instead of the original URI) in this case?
>> In other words, shouldn't the path passed to
>> mappingData.requestPath.setString(pathStr)
>> in Mapper.java be propagated to the request object associatd with the
>> mappingData?
>
>I consider welcome files to be internal forwards (since it is allowed to
>handle them this way). As a result, they shouldn't be matched by
>secrurity constraints. Only the original request path should be the used
>(so here it's getDecodedRequestURI - as sent by the client).
>
I agree with Remy. It's an internal Tomcat implementation detail that
welcome-files aren't handled via DefaultServlet doing:
RequestDispatcher rd = request.getRequestDispatcher(welcome[i]);
rd.forward(request, response);
Since this is explicitly allowed by the spec, nobody can expect that a
security-constraint mapped only to the welcome-file will be applied.
However, this is probably another thing that should be better specified in
the 2.5 spec.
>Rémy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm
RealmBase.java
Posted by Remy Maucherat <re...@apache.org>.
luehe@apache.org wrote:
> luehe 2005/03/02 11:27:11
>
> Modified: catalina/src/share/org/apache/catalina/realm RealmBase.java
> Log:
> Consider the case where original request was mapped to welcome page.
> In this case, the mapped welcome page (and not the original request
> URI!) needs to be the target of hasResourcePermission().
>
> This is consistent with the change that had been made in findSecurityConstraints().
>
> BTW, shouldn't request.getDecodedRequestURI() return the mapped
> welcome page (instead of the original URI) in this case?
> In other words, shouldn't the path passed to
> mappingData.requestPath.setString(pathStr)
> in Mapper.java be propagated to the request object associatd with the
> mappingData?
I consider welcome files to be internal forwards (since it is allowed to
handle them this way). As a result, they shouldn't be matched by
secrurity constraints. Only the original request path should be the used
(so here it's getDecodedRequestURI - as sent by the client).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org