DO NOT REPLY [Bug 25055] - getRemoteUser() returns null - bypass of apache authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25055. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25055 getRemoteUser() returns null - bypass of apache authentication --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 08:28 --- Ben, I did this already. The issue is that that using a .htaccess file does not protect tomcat served requests (*.jsp). It bypasses apache and does not ask for a login/password. I see this in apache 2.047 + tomcat 4.1.29 (both windows and linux) whereas apache 1.3.29 + tomcat 4.1.24 worked fine I do not know if this a tomcat or an apache issue. I'm going to write an email to tomcat-user to see if anyone else experiences this problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25279] New: - Tomcat don't write java out or err logs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25279. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25279 Tomcat don't write java out or err logs Summary: Tomcat don't write java out or err logs Product: Tomcat 5 Version: 5.0.16 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When I install tomcat as a service (Windows 2K) with --Java PATCH TO jvm.dll tomcat dosn't write java output or error files. The log file is locked, but the size of this file is always zero. When i change --Java to java (not jvm.dll) all works fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25279] - Tomcat don't write java out or err logs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25279. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25279 Tomcat don't write java out or err logs [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 10:05 --- You're supposed to use -Java java. Please don't attempt to use the service wrapper outside of the installer, nothing is documented (or well tested) at the moment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25241] - jsp:getProperty tag prints null if property is null.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25241. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25241 jsp:getProperty tag prints null if property is null. --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 10:06 --- Sorry, I think there was a misunderstanding: the spec is clear that null should be printed out, so we won't include a feature which violates the spec. So no patch will be accepted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.0.16 catalina.properties
1)
There seem to be 2 different catalina.properties:
jakarta-tomcat-5.0.16-src\jakarta-tomcat-catalina\catalina\src\conf\cata
lina.properties
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/li
b/*.jar
- this winds up in CATALINA_HOME/conf, but when the binary
tarball is expanded, the permissions are 600. So, in my case the file
does not get read
jakarta-tomcat-5.0.16-src\jakarta-tomcat-catalina\catalina\src\share\org
\apache\catalina\startup\catalina.properties
shared.loader=${catalina.home}/shared/classes,${catalina.home}/shared/li
b/*.jar
- this winds up inside bootstrap.jar. Note this version says
catalina.home, instead of catalina.base.
According to
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html
the second file is incorrect.
If multiple Tomcat instances are run from the same binary using
the $CATALINA_BASE environment variable, then this classloader
repositories are relative to $CATALINA_BASE rather than $CATALINA_HOME.
2)
By default, org/apache/catalina/startup/CatalinaProperties.java looks
for catalina.properties in CATALINA_HOME. Since the user might want to
customize a CATALINA_BASE directory, shouldn't it look in CATALINA_BASE?
3)
According to org/apache/catalina/startup/CatalinaProperties.java, the
location of catalina.properties can be specified via the catalina.config
option. Shouldn't that be documented in the catalina.properties file?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23745] - jsp.error.unterminated.tag received when doing struts tags - improve error messages for misbuilt tags!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23745. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23745 jsp.error.unterminated.tag received when doing struts tags - improve error messages for misbuilt tags! [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 13:26 --- so, if you want to get this fixed and have eclipse, use http://sourceforge.net/projects/lomboz/ and as per http://www.objectlearn.com/support/docs/debuggingJSP.jsp this may help (you also need http://www.sysdeo.com/eclipse/tomcatPlugin.html -- http://www.sysdeo.com/eclipse/jasperDebugPatchV4.1.24.zip) not fixing the root cause creates an entire industry ;) it could be so much easier! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25279] - Tomcat don't write java out or err logs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25279. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25279 Tomcat don't write java out or err logs --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 13:27 --- That is correct behavior (at least until the procrun2 gets working). Procrun (tomcat.exe) can write to stderr/stdout files only for redirected console apps (java.exe). Using java.exe is btw 'preffered' way of launching tomcat. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.16 catalina.properties
Marx, Mitchell E (Mitch), ALABS wrote:
1)
There seem to be 2 different catalina.properties:
jakarta-tomcat-5.0.16-src\jakarta-tomcat-catalina\catalina\src\conf\cata
lina.properties
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/li
b/*.jar
- this winds up in CATALINA_HOME/conf, but when the binary
tarball is expanded, the permissions are 600. So, in my case the file
does not get read
jakarta-tomcat-5.0.16-src\jakarta-tomcat-catalina\catalina\src\share\org
\apache\catalina\startup\catalina.properties
shared.loader=${catalina.home}/shared/classes,${catalina.home}/shared/li
b/*.jar
- this winds up inside bootstrap.jar. Note this version says
catalina.home, instead of catalina.base.
According to
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html
the second file is incorrect.
If multiple Tomcat instances are run from the same binary using
the $CATALINA_BASE environment variable, then this classloader
repositories are relative to $CATALINA_BASE rather than $CATALINA_HOME.
Ok.
2)
By default, org/apache/catalina/startup/CatalinaProperties.java looks
for catalina.properties in CATALINA_HOME. Since the user might want to
customize a CATALINA_BASE directory, shouldn't it look in CATALINA_BASE?
No, it's global (and defines where the binaries are).
3)
According to org/apache/catalina/startup/CatalinaProperties.java, the
location of catalina.properties can be specified via the catalina.config
option. Shouldn't that be documented in the catalina.properties file?
I don't know if this works (it looks like it would, though).
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24763] - Apache-Tomcat comm fails streaming objects of certain predictble sizes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24763.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24763
Apache-Tomcat comm fails streaming objects of certain predictble sizes
--- Additional Comments From [EMAIL PROTECTED] 2003-12-08 14:35 ---
some easy steps to reproduce this kind of error
(in short, parameter value of some certain length gets
changed in transit - last character of the parameter value
gets equal to '\u' instead of '\u0030' which was originally
sent)
1) create a jsp - say bb.jsp
%
String v = request.getParameter(v);
int LEN=8185;
for( int i=0; iLEN; i++ ){
System.err.println(i+=+(int)v.charAt(i));
}
%
2)
run the following (change your-host-apache-tomcat with real path) -
that code will make a POST request to bb.jsp
static void testJK2bug() throws Exception {
int LEN = 8185;
URL u = new URL(http://your-host-apache-tomcat/bb.jsp;);
URLConnection uc = u.openConnection();
uc.setRequestProperty(Content-Type, application/x-www-form-urlencoded);
StringBuffer val = new StringBuffer(v=);
for (int j = 0; j LEN; j++) {
val.append(0);
}
uc.setRequestProperty(Content-Length, + val.length());
uc.setDoOutput(true);
uc.getOutputStream().write(val.toString().getBytes());
uc.getInputStream().read();
}
3) see in catalina.out that last character in the parameter value
is '\u' , not '\u0030' as it should be
That kind of problem (filling with 0-es) is not limited to single byte.
Out production site sometimes experiences blocks of zeroes
somehow becoming parameter names/values, so the problem is rather critical.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/jsr154/examples helloworld.html
jfarcand2003/12/08 07:38:29 Modified:jsr154/examples helloworld.html Log: Apply patch from Mark Thomas (medthomas at ntlworld dot com) Revision ChangesPath 1.3 +0 -1 jakarta-servletapi-5/jsr154/examples/helloworld.html Index: helloworld.html === RCS file: /home/cvs/jakarta-servletapi-5/jsr154/examples/helloworld.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- helloworld.html 29 Oct 2002 17:42:57 - 1.2 +++ helloworld.html 8 Dec 2003 15:38:29 - 1.3 @@ -21,7 +21,6 @@ response.setContentType(quot;font color=#009900text/html/fontquot;); PrintWriter out = response.getWriter(); out.println(quot;font color=#009900lt;htmlgt;/fontquot;); -out.println(quot;font color=#009900lt;bodygt;/fontquot;); out.println(quot;font color=#009900lt;headgt;/fontquot;); out.println(quot;font color=#009900lt;titlegt;Hello World!lt;/titlegt;/fontquot;); out.println(quot;font color=#009900lt;/headgt;/fontquot;); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/webapps/examples/servlets helloworld.html
jfarcand2003/12/08 07:40:42 Modified:webapps/examples/servlets helloworld.html Log: Port patch. Revision ChangesPath 1.2 +0 -1 jakarta-tomcat-4.0/webapps/examples/servlets/helloworld.html Index: helloworld.html === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/servlets/helloworld.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- helloworld.html 17 Aug 2000 00:58:20 - 1.1 +++ helloworld.html 8 Dec 2003 15:40:42 - 1.2 @@ -21,7 +21,6 @@ response.setContentType(quot;font color=#009900text/html/fontquot;); PrintWriter out = response.getWriter(); out.println(quot;font color=#009900lt;htmlgt;/fontquot;); -out.println(quot;font color=#009900lt;bodygt;/fontquot;); out.println(quot;font color=#009900lt;headgt;/fontquot;); out.println(quot;font color=#009900lt;titlegt;Hello World!lt;/titlegt;/fontquot;); out.println(quot;font color=#009900lt;/headgt;/fontquot;); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.16 catalina.properties
Hi, 3) According to org/apache/catalina/startup/CatalinaProperties.java, the location of catalina.properties can be specified via the catalina.config option. Shouldn't that be documented in the catalina.properties file? I don't know if this works (it looks like it would, though). Rémy I've tested this option. If you pass in startup -Dcatalina.config=PATH-TO-catalina.properties Tomcat uses the specified properties-file. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup catalina.properties
remm2003/12/08 09:28:31
Modified:catalina/src/share/org/apache/catalina/startup
catalina.properties
Log:
- Sync with the main catalina.properties.
Revision ChangesPath
1.5 +3 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/catalina.properties
Index: catalina.properties
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/catalina.properties,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- catalina.properties 26 Sep 2003 19:31:16 - 1.4
+++ catalina.properties 8 Dec 2003 17:28:31 - 1.5
@@ -1,10 +1,10 @@
-##
+#
# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
# passed to checkPackageAccess unless the
# corresponding RuntimePermission (accessClassInPackage.+package) has
# been granted.
-package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.
+package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.,sun.beans.
#
# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
@@ -52,4 +52,4 @@
# foo/*.jar: Add all the JARs of the specified folder as class
# repositories
# foo/bar.jar: Add bar.jar as a class repository
-shared.loader=${catalina.home}/shared/classes,${catalina.home}/shared/lib/*.jar
+shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Servlet Examples
Done Thanks, -- Jeanfrancois Mark Thomas wrote: Noticed this while looking at the examples. Worth making sure we get this sort of thing right. Mark Index: webapps/examples/servlets/helloworld.html === RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/servlets/helloworld.html,v retrieving revision 1.1 diff -u -r1.1 helloworld.html --- webapps/examples/servlets/helloworld.html 17 Aug 2000 00:58:20 - 1.1 +++ webapps/examples/servlets/helloworld.html 6 Dec 2003 18:47:56 - @@ -21,7 +21,6 @@ response.setContentType(quot;font color=#009900text/html/fontquot;); PrintWriter out = response.getWriter(); out.println(quot;font color=#009900lt;htmlgt;/fontquot;); -out.println(quot;font color=#009900lt;bodygt;/fontquot;); out.println(quot;font color=#009900lt;headgt;/fontquot;); out.println(quot;font color=#009900lt;titlegt;Hello World!lt;/titlegt;/fontquot;); out.println(quot;font color=#009900lt;/headgt;/fontquot;); Index: jsr154/examples/helloworld.html === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr154/examples/helloworld.html,v retrieving revision 1.2 diff -u -r1.2 helloworld.html --- jsr154/examples/helloworld.html 29 Oct 2002 17:42:57 - 1.2 +++ jsr154/examples/helloworld.html 6 Dec 2003 18:49:44 - @@ -21,7 +21,6 @@ response.setContentType(quot;font color=#009900text/html/fontquot;); PrintWriter out = response.getWriter(); out.println(quot;font color=#009900lt;htmlgt;/fontquot;); -out.println(quot;font color=#009900lt;bodygt;/fontquot;); out.println(quot;font color=#009900lt;headgt;/fontquot;); out.println(quot;font color=#009900lt;titlegt;Hello World!lt;/titlegt;/fontquot;); out.println(quot;font color=#009900lt;/headgt;/fontquot;); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22867] - Tag handlers can't be inner/nested classes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22867. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22867 Tag handlers can't be inner/nested classes --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 19:07 --- Can someone clarify what will happen now. Will tagclassA$B/tagclass be converted to A.B in the generated .java file (if not, then javac 1.4.2+ will fail)? Also, will this fix be in Tomcat 4.x branch? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25338] New: - URI Rewrite does not function according to Servlet2.3 specifications (jsession= , servlet-mapping filter-mapping)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25338. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25338 URI Rewrite does not function according to Servlet2.3 specifications (jsession= , servlet-mapping filter-mapping) Summary: URI Rewrite does not function according to Servlet2.3 specifications (jsession= , servlet-mapping filter- mapping) Product: Tomcat 4 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A URI is improperly distpatched when the ;jsession=xxx is added to the URI. The catalina lookup uses everything from the URI:hostname:port to the ? delimiter to define a resource. When ;jsession=xxx is added upon the uri for return the resource is not found. The published FIX is to enable the apache- web-server's mod_rewrite and have the webserver fix this for tomcat... this is an inappropriate fix. Since tomcat is bundled in Jboss as a stand-alone webservice (and when tested in stand-alone, without apache), it can not use the apache-mod_rewrite hack. The catalina module needs to correctly handle the resource information, if the ;jsession=xxx is not within spec, then for compliance to spec this habit will have to change. Another bug discovered while debugging this issue... The filter-mapping /* does not filter calls to the traditional servlet- mapping=*.do for struts. This breaks the filter-mapping concept. Luckily for me the ;jsession=xxx bug is not caught by the servlet *.do mapping and my filter can catch this to reroute it to the appropriate resource. I suggest looking into the Catilina dispatcher and uri parsing semantics I do not have time to fully debug this :( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25263] - Incorrect SMAP generated for JSP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25263. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25263 Incorrect SMAP generated for JSP --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 00:03 --- Argh! When I concatenated adjecent template text strings, I forgot to update the smap too! I'll try to fix this. In the meantime, use the compiler option 'mappedfile' as a workaround, which you may want to do anyway when debugging. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationFilterFactory.java
amyroh 2003/12/08 16:50:28
Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterFactory.java
Log:
Strip out uri parameters (;*) during filter mappings or security constraints
matching - bugtraq 4903209.
Revision ChangesPath
1.12 +7 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java
Index: ApplicationFilterFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ApplicationFilterFactory.java 2 Sep 2003 21:22:04 - 1.11
+++ ApplicationFilterFactory.java 9 Dec 2003 00:50:28 - 1.12
@@ -156,6 +156,10 @@
if (attribute != null){
requestPath = attribute.toString();
+int semicolon = requestPath.indexOf(;);
+if (semicolon = 0) {
+requestPath = requestPath.substring(0, semicolon);
+}
}
HttpServletRequest hreq = null;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
amyroh 2003/12/08 16:50:58
Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java
Log:
Strip out uri parameters (;*) during filter mappings or security constraints
matching - bugtraq 4903209.
Revision ChangesPath
1.18 +16 -4
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.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- RealmBase.java2 Sep 2003 21:22:05 - 1.17
+++ RealmBase.java9 Dec 2003 00:50:58 - 1.18
@@ -460,6 +460,18 @@
String contextPath = hreq.getContextPath();
if (contextPath.length() 0)
uri = uri.substring(contextPath.length());
+
+if (uri != null) {
+int semicolon = uri.indexOf(;);
+if (semicolon = 0) {
+String baseuri = uri.substring(0, semicolon);
+if (debug = 2)
+log(Request uri ' + uri + ' treated as ' + baseuri +
+' for security constraint matching.);
+uri = baseuri;
+}
+}
+
String method = hreq.getMethod();
for (int i = 0; i constraints.length; i++) {
if (log.isDebugEnabled())
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans ServerLifecycleListener.java
amyroh 2003/12/08 16:51:47
Modified:catalina/src/share/org/apache/catalina/mbeans
ServerLifecycleListener.java
Log:
Fix indentation.
Revision ChangesPath
1.12 +38 -38
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
Index: ServerLifecycleListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ServerLifecycleListener.java 25 Sep 2003 12:49:01 - 1.11
+++ ServerLifecycleListener.java 9 Dec 2003 00:51:47 - 1.12
@@ -152,41 +152,41 @@
/**
* MX4J adaptor name.
*/
- protected String adaptor = null;
+protected String adaptor = null;
- public String getAdaptor() {
- return (this.adaptor);
- }
-
- public void setAdaptor(String adaptor) {
- this.adaptor = adaptor;
- }
-
- /**
- * MX4J jrmp/iiop listen host
- */
- protected String adaptorHost = null;
-
- public String getAdaptorHost() {
- return (this.adaptorHost);
- }
-
- public void setAdaptorHost(String adaptorHost) {
- this.adaptorHost = adaptorHost;
- }
-
- /**
- * MX4J jrmp/iiop listen port
- */
- protected int adaptorPort = -1;
-
- public int getAdaptorPort() {
- return (this.adaptorPort);
- }
-
- public void setAdaptorPort(int adaptorPort) {
- this.adaptorPort = adaptorPort;
- }
+public String getAdaptor() {
+return (this.adaptor);
+}
+
+public void setAdaptor(String adaptor) {
+this.adaptor = adaptor;
+}
+
+/**
+ * MX4J jrmp/iiop listen host
+ */
+protected String adaptorHost = null;
+
+public String getAdaptorHost() {
+return (this.adaptorHost);
+}
+
+public void setAdaptorHost(String adaptorHost) {
+this.adaptorHost = adaptorHost;
+}
+
+/**
+ * MX4J jrmp/iiop listen port
+ */
+protected int adaptorPort = -1;
+
+public int getAdaptorPort() {
+return (this.adaptorPort);
+}
+
+public void setAdaptorPort(int adaptorPort) {
+this.adaptorPort = adaptorPort;
+}
// -- ContainerListener Methods
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25263] - Incorrect SMAP generated for JSP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25263. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25263 Incorrect SMAP generated for JSP --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 00:54 --- The suggested workaround of setting mappedfile to true works perfectly, once all the previously compiled JSP state is removed from the Tomcat work directory. Thank you very much for the suggestion. By the way, the default Tomcat settings are basically set up for debugging, except for mappedfile. For example, checkInterval, classdebuginfo, development, keepgenerated, reloading are all set to development/debug settings by default. Is there some special reason that mappedfile is not set accordingly? Should it be? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java
amyroh 2003/12/08 17:54:33
Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterFactory.java
catalina/src/share/org/apache/catalina/realm RealmBase.java
Log:
Revert the patch. Seems like this case is already handled in the Mapper in TC5.
Revision ChangesPath
1.13 +3 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java
Index: ApplicationFilterFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ApplicationFilterFactory.java 9 Dec 2003 00:50:28 - 1.12
+++ ApplicationFilterFactory.java 9 Dec 2003 01:54:33 - 1.13
@@ -156,10 +156,6 @@
if (attribute != null){
requestPath = attribute.toString();
-int semicolon = requestPath.indexOf(;);
-if (semicolon = 0) {
-requestPath = requestPath.substring(0, semicolon);
-}
}
HttpServletRequest hreq = null;
1.19 +4 -15
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.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- RealmBase.java9 Dec 2003 00:50:58 - 1.18
+++ RealmBase.java9 Dec 2003 01:54:33 - 1.19
@@ -461,17 +461,6 @@
if (contextPath.length() 0)
uri = uri.substring(contextPath.length());
-if (uri != null) {
-int semicolon = uri.indexOf(;);
-if (semicolon = 0) {
-String baseuri = uri.substring(0, semicolon);
-if (debug = 2)
-log(Request uri ' + uri + ' treated as ' + baseuri +
-' for security constraint matching.);
-uri = baseuri;
-}
-}
-
String method = hreq.getMethod();
for (int i = 0; i constraints.length; i++) {
if (log.isDebugEnabled())
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Hi all, I am new to Tomcat's mailing lists, and I don't really know if this list is the right place for such a post : excuse me if it is not the case. I wonder if I didn't notice something which is not a real bug in Tomcat, as it seems to do exactly what developers want it to do, but more a difference between the implementation of authorization policy (the handling of a Web Application web.xml security-constraint elements) in Tomcat5 and what the Servlet 2.4 Spec says. Example of the problem (from the Tomcat Jsp-examples WebApp) : ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=tomcat/ role rolename=role1/ role rolename=manager/ role rolename=admin/ user username=tomcat password=tomcat roles=tomcat/ user username=both password=tomcat roles=tomcat,role1/ user username=role1 password=tomcat roles=role1/ user username=admin password=tomcat roles=admin,manager,tomcat/ /tomcat-users tomcat-users.xml security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-nametomcat/role-name /auth-constraint /security-constraint security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-namerole1/role-name /auth-constraint /security-constraint !-- Default login configuration uses form-based authentication -- login-config auth-methodFORM/auth-method realm-nameExample Form-Based Authentication Area/realm-name form-login-config form-login-page/security/protected/login.jsp/form-login-page form-error-page/security/protected/error.jsp/form-error-page /form-login-config /login-config !-- Security roles referenced by this web application -- security-role role-namerole1/role-name /security-role security-role role-nametomcat/role-name /security-role webapps/jsp-examples/WEB-INF/web.xml (excerpt) I've been adding a new security-constraint element, separing the authorized roles each in its security-constraint According to what the Servlet 2.4 says (see below for exact reference), two security constraints on the same (url-pattern, http-method) should result in the addition of the given authorizations and so in this case, users tomcat, role1 and both should be authorized to access the protected resource. But here, it is the contrary : you can't access http://10.160.4.205:8080/jsp-examples/security/protected/ under tomcat or role1 identity any more, but you can still using the both identity : Tomcat has realized the intersection of the authorizations instead of doing the union. Analyze of the problem After inverstigating a while in the code, here is what I noticed : First, In SecurityConstraint[] RealmBase.findSecurityConstraints(HttpRequest request, Context context) (the method begins at l. 445 of the org.apache.catalina.realm.RealmBase file), each and every SecurityConstraint (= security-constraint in web.xml) containing a SecurityCollection (= web-ressource-collection in web.xml) containing a url-pattern matching the User's request URI and defining a restriction on the http-method used by the user for his request is retrieved, using boolean SecurityConstraint.included(String uri, String method) (method starts at line 343 of org.apache.catalina.deploy.SecurityConstraint) While only SecurityConstraints containing SecurityCollections containing the url-pattern which is the best-match to the User's request URI amongst all the url-patterns defined in web.xml should be retained first, and then amongst these remaining constraints we shall keep only the ones defining a restriction on the same method (or no restriction on the method, as stated in servlet-2_4-fr-spec.pdf, ch SRV 12-8-3, pp 100-101) Second in public boolean hasResourcePermission(HttpRequest request, HttpResponse response, SecurityConstraint constraint, Context context) (the method begins at line 501 of the org.apache.catalina.realm.RealmBase file) the restrictions on the
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler SmapUtil.java
kinman 2003/12/08 18:51:35
Modified:jasper2/src/share/org/apache/jasper/compiler SmapUtil.java
Log:
- Fix 25263: bad smap when template text got concatenated.
Revision ChangesPath
1.21 +6 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/SmapUtil.java
Index: SmapUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/SmapUtil.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- SmapUtil.java 22 Oct 2003 19:10:58 - 1.20
+++ SmapUtil.java 9 Dec 2003 02:51:35 - 1.21
@@ -613,19 +613,22 @@
//Add a LineInfo that corresponds to the beginning of this node
int iInputStartLine = mark.getLineNumber();
int iOutputStartLine = n.getBeginJavaLine();
-smap.addLineData(iInputStartLine, fileName, 1, iOutputStartLine, 1);
+int iOutputLineIncrement = breakAtLF? 1: 0;
+smap.addLineData(iInputStartLine, fileName, 1, iOutputStartLine,
+ iOutputLineIncrement);
// Output additional mappings in the text
java.util.ArrayList extraSmap = n.getExtraSmap();
if (extraSmap != null) {
for (int i = 0; i extraSmap.size(); i++) {
+iOutputStartLine += iOutputLineIncrement;
smap.addLineData(
iInputStartLine+((Integer)extraSmap.get(i)).intValue(),
fileName,
1,
-++iOutputStartLine,
-1);
+iOutputStartLine,
+iOutputLineIncrement);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25263] - Incorrect SMAP generated for JSP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25263. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25263 Incorrect SMAP generated for JSP [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 02:54 --- Maybe it should. Come to think of it, we should just set a single flag, such as 'development', to turn on/off debugging. So setting development would set some reasbable default for checkInterval, classdebuginfo, development, keepgenerated, reloading, and mappedfile. What do you think? Anyway, this bug is fixed now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25263] - Incorrect SMAP generated for JSP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25263. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25263 Incorrect SMAP generated for JSP --- Additional Comments From [EMAIL PROTECTED] 2003-12-09 03:23 --- I think a global flag that set some reasonable debug settings would be fantastic and make configuration much simpler. And, thanks for fixing the bug. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Yes, this looks like it changed between pfd3 to fr :(. Security-constraints now work like 'grants' instead of 'constraints'. IMHO, this make the 2.4 security model all but useless. whine It would be natural to configure something like: security-constraint web-resource-collection web-resource-nameClient Area/web-resource-name url-pattern/clients/*/url-pattern /web-resource-collection auth-constraint !-- Any authenticated user -- role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct1 Client Area/web-resource-name url-pattern/clients/product1/*/url-pattern /web-resource-collection auth-constraint !-- Any product1 user -- role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct2 Client Area/web-resource-name url-pattern/clients/product2/*/url-pattern /web-resource-collection auth-constraint !-- Any product2 user -- role-nameproduct2/role-name /auth-constraint /security-constraint The way the 2.4 spec is written, all authenticated users have access to everything under /myapp/clients/. To get what I want is now a configuration nightmare :(. /whine Now back to fixing things. I sort of like the idea of changing the Realm interface so that 'hasUserDataPermissions' and 'hasResourcePermissions' take a SecurityConstraint []. However, after a GA release, this may be a bit much. Philippe's solution looks a bit over-kill to me, but I'm not going to object if someone wants to commit it. I'm thinking of moving the header-setting stuff out of RealmBase and into AuthenticatorBase. It may cause some custom realms to stop working, but there shouldn't be that many for TC 5 yet :). Of course, I'm volunteering for the code-monkey (copy; Pier) part of this. Since anyway we go is a pretty big change, I just wanted to get a consensus first. Opinions, Comments, Flames? - Original Message - From: philippe.leothaud [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 08, 2003 6:43 PM Subject: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec Hi all, I am new to Tomcat's mailing lists, and I don't really know if this list is the right place for such a post : excuse me if it is not the case. I wonder if I didn't notice something which is not a real bug in Tomcat, as it seems to do exactly what developers want it to do, but more a difference between the implementation of authorization policy (the handling of a Web Application web.xml security-constraint elements) in Tomcat5 and what the Servlet 2.4 Spec says. Example of the problem (from the Tomcat Jsp-examples WebApp) : ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=tomcat/ role rolename=role1/ role rolename=manager/ role rolename=admin/ user username=tomcat password=tomcat roles=tomcat/ user username=both password=tomcat roles=tomcat,role1/ user username=role1 password=tomcat roles=role1/ user username=admin password=tomcat roles=admin,manager,tomcat/ /tomcat-users tomcat-users.xml security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-nametomcat/role-name /auth-constraint /security-constraint security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-namerole1/role-name /auth-constraint /security-constraint !-- Default login configuration uses form-based authentication -- login-config auth-methodFORM/auth-method realm-nameExample Form-Based Authentication Area/realm-name form-login-config form-login-page/security/protected/login.jsp/form-login-page form-error-page/security/protected/error.jsp/form-error-page /form-login-config /login-config !-- Security roles referenced by this web application -- security-role role-namerole1/role-name /security-role
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Hi Bill, I totally agree with you, this security model is going to be a pain somewhere to correctly configure access rights... As of my solution, the real interest is that (as far as I can see) it doesn't change at all any API : the only thing that changes is the body of the method SecurityConstraint[] findSecurityConstraints(HttpRequest request, Context context) in org.apache.catalina.realm.RealmBase (starting at line 438), I only changed the body so that it calls the new MergedConstraintBuilder class. In any case, the signature remains the same. Today : 1- AuthenticatorBase gets all possible Constraints mathing the request, by calling SecurityConstraint [] constraints = realm.findSecurityConstraints(hrequest, this.context); (AuthenticatorBase , l. 502) 2- RealmBase handles that request, returning an array of all the Constraints matching the URI and the HTTP method of the request 3- AuthenticatorBase retrieves all these Constraints, cast the Request and Response into HttpServletRequest and HttpServletResponse (l 515-525) 4- For each Constraint of the array, AuthenticatorBase asks RealmBase if the UserDataPermission is OK 5- For each Constraint of the array, AuthenticatorBase asks RealmBase if the AuthConstraint is OK All that I change is what is happening in step 2 : - RealmBase asks the new Class to retrieve an Array of matching Constraints - The new Class builds a fake Constraint representing all possible AuthConstraints and UserDataConstraints for this (URI, HTTPMethod) - It returns an array of SecurityConstraints, just like before. The only difference is that now this array has only one (or zero) element, but neither RealmBase neither AuthenticatorBase are aware of that. All the remaining methods calls are just the same, they will just be faster because there is only one Constraint in the array (and I think that if the 10 lines of code needed to cache the fake Constraints are added in this new Class, it may really be faster and compute-time saving) . I used that for a custom authorization framework I'm working on and it's OK for me. Thanks for having replied quickly (It's difficult to work seriously while you're looking at your mail-box every minute to see if a response wasn't posted ;-) - Original Message - From: Bill Barker [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 09, 2003 6:00 AM Subject: Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec Yes, this looks like it changed between pfd3 to fr :(. Security-constraints now work like 'grants' instead of 'constraints'. IMHO, this make the 2.4 security model all but useless. whine It would be natural to configure something like: security-constraint web-resource-collection web-resource-nameClient Area/web-resource-name url-pattern/clients/*/url-pattern /web-resource-collection auth-constraint !-- Any authenticated user -- role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct1 Client Area/web-resource-name url-pattern/clients/product1/*/url-pattern /web-resource-collection auth-constraint !-- Any product1 user -- role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct2 Client Area/web-resource-name url-pattern/clients/product2/*/url-pattern /web-resource-collection auth-constraint !-- Any product2 user -- role-nameproduct2/role-name /auth-constraint /security-constraint The way the 2.4 spec is written, all authenticated users have access to everything under /myapp/clients/. To get what I want is now a configuration nightmare :(. /whine Now back to fixing things. I sort of like the idea of changing the Realm interface so that 'hasUserDataPermissions' and 'hasResourcePermissions' take a SecurityConstraint []. However, after a GA release, this may be a bit much. Philippe's solution looks a bit over-kill to me, but I'm not going to object if someone wants to commit it. I'm thinking of moving the header-setting stuff out of RealmBase and into AuthenticatorBase. It may cause some custom realms to stop working, but there shouldn't be that many for TC 5 yet :). Of course, I'm volunteering for the code-monkey (copy; Pier) part of this. Since anyway we go is a pretty big change, I just wanted to get a consensus first. Opinions, Comments, Flames? - Original Message - From: philippe.leothaud [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 08, 2003 6:43 PM Subject: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec - To unsubscribe,
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Ok, I take back my whine/. It seems that they have really made a hash out of the security-constraints. Something like Philippe's implementation is required. Section 12.8.3 requires that only the 'best match' constraints are processed, and those in a 'grant' fashion (i.e. you get the least restrictive privilege of the most restrictive constraints). Now you just need to be a rocket-scientist to figure out how your security-constraints work ;-). So in my example below, a request for /myapp/clients/product1/ will only consider the 'product1' constraint, and ignore the constraint for '/clients/*'. If I had added a security-constraint for '*.jsp', then a request for /myapp/clients/product1/index.jsp would use the 'product1' constraint, and ignore the '*.jsp' constraint. Isn't life going to be fun on the user-list ;-). This means that RealmBase.findSecurityConstraints is going to have to change to only pass back the 'best-match' constraints. At least this isn't an interface change. The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. - Original Message - From: Bill Barker [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, December 08, 2003 9:00 PM Subject: Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec Yes, this looks like it changed between pfd3 to fr :(. Security-constraints now work like 'grants' instead of 'constraints'. IMHO, this make the 2.4 security model all but useless. whine It would be natural to configure something like: security-constraint web-resource-collection web-resource-nameClient Area/web-resource-name url-pattern/clients/*/url-pattern /web-resource-collection auth-constraint !-- Any authenticated user -- role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct1 Client Area/web-resource-name url-pattern/clients/product1/*/url-pattern /web-resource-collection auth-constraint !-- Any product1 user -- role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct2 Client Area/web-resource-name url-pattern/clients/product2/*/url-pattern /web-resource-collection auth-constraint !-- Any product2 user -- role-nameproduct2/role-name /auth-constraint /security-constraint The way the 2.4 spec is written, all authenticated users have access to everything under /myapp/clients/. To get what I want is now a configuration nightmare :(. /whine Now back to fixing things. I sort of like the idea of changing the Realm interface so that 'hasUserDataPermissions' and 'hasResourcePermissions' take a SecurityConstraint []. However, after a GA release, this may be a bit much. Philippe's solution looks a bit over-kill to me, but I'm not going to object if someone wants to commit it. I'm thinking of moving the header-setting stuff out of RealmBase and into AuthenticatorBase. It may cause some custom realms to stop working, but there shouldn't be that many for TC 5 yet :). Of course, I'm volunteering for the code-monkey (copy; Pier) part of this. Since anyway we go is a pretty big change, I just wanted to get a consensus first. Opinions, Comments, Flames? - Original Message - From: philippe.leothaud [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 08, 2003 6:43 PM Subject: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec Hi all, I am new to Tomcat's mailing lists, and I don't really know if this list is the right place for such a post : excuse me if it is not the case. I wonder if I didn't notice something which is not a real bug in Tomcat, as it seems to do exactly what developers want it to do, but more a difference between the implementation of authorization policy (the handling of a Web Application web.xml security-constraint elements) in Tomcat5 and what the Servlet 2.4 Spec says. Example of the problem (from the Tomcat Jsp-examples WebApp) : ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=tomcat/ role rolename=role1/ role rolename=manager/ role rolename=admin/ user username=tomcat password=tomcat roles=tomcat/ user username=both password=tomcat roles=tomcat,role1/ user username=role1 password=tomcat roles=role1/ user username=admin password=tomcat roles=admin,manager,tomcat/ /tomcat-users tomcat-users.xml security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected --
Placement of Tag Library Descriptor
Hello. I am using Tomcat 4.1.24 on Mac OS 10.3 and when I place the tld file used by my web application in /Test/tlds(where Test is the name of the application), I get a 404 Error. When I place the same tld file in /Test, everything works fine. Does anyone know why this is happening? Apparently, the application is able to find the tld since the Tomcat logs show no errors. Any help would be greatly appreciated. Thanks. - Asad __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Placement of JSP/HTML Files
Hello. Does anyone know if there is a way to place your JSP/HTML files in a subfolder of the root level directory instead of in the root level directory. For example, if I have a web app named Test, I would like to place my files in /Test/jsp instead of in /Test. Your help would be greatly appreciated. Thanks. - Asad __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
