%3F Problem
This may be a bit obscure, but I'm trying to get Tomcat to respond to a request that arrives with an encoded URL in the form [URL]%3F[Parameters]. It looks like "http://myhost:myport/mycontext/servlet/myservlet%3Fx=y" If I do the equivalent with an Apache http server (for verifying that I'm trying the right thing), I get the error message indicating that Apache was looking for the correct URL followed by a question mark and the name-value pairs of the parameter list. In Tomcat, however, the %3F does not get replaced and the error message indicates that Tomcat is looking for a servlet class called "myservlet%3Fx=y" which does not exist on my system. It looks like somebody must have attempted to fix this since the b3 version does a correct replacement if the %3F shows up right behind the end of the context (/mycontext/servlet%3F). I would volunteer to attempt a fix, if someone could point me to the right files - I looked at StandardWrapper and StandardClassLoader, and I can get the class loaded by cutting the name before the %, but then I lose the parameter list. Any hints? TIA
Re: %3F Problem
I find out some problem with this. Encoding som other characters then ISO Latin 1 from %xx URL fromat. With URL encoding deals: in tomcat: org.apache.tomcat.core.RequestImpl.handleParameters(); ... this use some methods from the same class but the same thinh does: in servlet spec: javax.servlet.http.HttpUtils.parseQueryString() I thing is better to use one implementation of parsing URL. (I posted the code in "Support for different Charsets" tread) Hi Jan Fnukal e-mail: [EMAIL PROTECTED] tel: +420-5-4142 5628 EfCon a.s. Jaselska 25 611 57 Brno Czech Republic www.efcon.cz - Original Message - From: Klaus Sonnenleiter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 13, 2001 4:40 PM Subject: %3F Problem This may be a bit obscure, but I'm trying to get Tomcat to respond to a request that arrives with an encoded URL in the form [URL]%3F[Parameters]. It looks like "http://myhost:myport/mycontext/servlet/myservlet%3Fx=y" If I do the equivalent with an Apache http server (for verifying that I'm trying the right thing), I get the error message indicating that Apache was looking for the correct URL followed by a question mark and the name-value pairs of the parameter list. In Tomcat, however, the %3F does not get replaced and the error message indicates that Tomcat is looking for a servlet class called "myservlet%3Fx=y" which does not exist on my system. It looks like somebody must have attempted to fix this since the b3 version does a correct replacement if the %3F shows up right behind the end of the context (/mycontext/servlet%3F). I would volunteer to attempt a fix, if someone could point me to the right files - I looked at StandardWrapper and StandardClassLoader, and I can get the class loaded by cutting the name before the %, but then I lose the parameter list. Any hints? TIA
Re: %3F Problem
Oops, I guess I should have mentioned that I'm using the 4.0 version. Do you happen to know where the RequestImpl or equivalent class is in catalina? (I checked org.apache.catalina.core.* without success). At 05:09 PM 4/13/01 +0200, you wrote: I find out some problem with this. Encoding som other characters then ISO Latin 1 from %xx URL fromat. With URL encoding deals: in tomcat: org.apache.tomcat.core.RequestImpl.handleParameters(); ... this use some methods from the same class but the same thinh does: in servlet spec: javax.servlet.http.HttpUtils.parseQueryString() I thing is better to use one implementation of parsing URL. (I posted the code in "Support for different Charsets" tread) Hi Jan Fnukal e-mail: [EMAIL PROTECTED] tel: +420-5-4142 5628 EfCon a.s. Jaselska 25 611 57 Brno Czech Republic www.efcon.cz - Original Message - From: Klaus Sonnenleiter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, April 13, 2001 4:40 PM Subject: %3F Problem This may be a bit obscure, but I'm trying to get Tomcat to respond to a request that arrives with an encoded URL in the form [URL]%3F[Parameters]. It looks like "http://myhost:myport/mycontext/servlet/myservlet%3Fx=y" If I do the equivalent with an Apache http server (for verifying that I'm trying the right thing), I get the error message indicating that Apache was looking for the correct URL followed by a question mark and the name-value pairs of the parameter list. In Tomcat, however, the %3F does not get replaced and the error message indicates that Tomcat is looking for a servlet class called "myservlet%3Fx=y" which does not exist on my system. It looks like somebody must have attempted to fix this since the b3 version does a correct replacement if the %3F shows up right behind the end of the context (/mycontext/servlet%3F). I would volunteer to attempt a fix, if someone could point me to the right files - I looked at StandardWrapper and StandardClassLoader, and I can get the class loaded by cutting the name before the %, but then I lose the parameter list. Any hints? TIA
Re: %3F Problem
On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Oops, I guess I should have mentioned that I'm using the 4.0 version. Do you happen to know where the RequestImpl or equivalent class is in catalina? (I checked org.apache.catalina.core.* without success). The base class is org.apache.catalina.connector.HttpRequestBase. The 1.1 connector subclasses this as org.apache.catalina.connector.http.HttpRequestImpl. Craig
Re: %3F Problem
Craig, I looked at HttpRequestImpl. Would it be safe to manipulate the URI in a call to setRequestURI before it sets the instance variable requestURI? It seems like this gets called the moment a request is made - this way, the encoded characters could be transformed to their unencoded equivalents before the parameter list is parsed and the classloader gets called. Klaus At 09:34 AM 4/13/01 -0700, you wrote: On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Oops, I guess I should have mentioned that I'm using the 4.0 version. Do you happen to know where the RequestImpl or equivalent class is in catalina? (I checked org.apache.catalina.core.* without success). The base class is org.apache.catalina.connector.HttpRequestBase. The 1.1 connector subclasses this as org.apache.catalina.connector.http.HttpRequestImpl. Craig
Re: %3F Problem
On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Craig, I looked at HttpRequestImpl. Would it be safe to manipulate the URI in a call to setRequestURI before it sets the instance variable requestURI? It seems like this gets called the moment a request is made - this way, the encoded characters could be transformed to their unencoded equivalents before the parameter list is parsed and the classloader gets called. Klaus The key thing to remember is a spec requirement that request.getRequestURI() must return the original request URI *without* decoding. The values returned by request.getServletPath() and request.getPathInfo(), on the other hand, are decoded first. Therefore, if you manipulate the request URI value in setRequestURI(), we'd need to make sure that we save an unmanipulated version somewhere as well. The deeper issue, though, is the portability of what you are proposing (across servlet containers) would be. As I understand it, you would like the %3f character to be interpreted as a "?" character so that the stuff after it is understood as part of the query string. That seems (to me) a questionable practice -- the reason you would use a %3f encoding in the first place is so that you could treat a question mark as a regular data character, instead of being a significant delimiter. If you decode first and then find that the "?" is significant, how would you ever include a question mark as part of the data value for a query string parameter (for example)? NOTE: There also needs to be a little more work in this area with respect to path parameters (;xxx stuff, which is how the session id is transmitted). This is being discussed in the expert group, and will probably require some minor changes in this area of Tomcat 4. Craig At 09:34 AM 4/13/01 -0700, you wrote: On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Oops, I guess I should have mentioned that I'm using the 4.0 version. Do you happen to know where the RequestImpl or equivalent class is in catalina? (I checked org.apache.catalina.core.* without success). The base class is org.apache.catalina.connector.HttpRequestBase. The 1.1 connector subclasses this as org.apache.catalina.connector.http.HttpRequestImpl. Craig
Re: %3F Problem
Craig, since I'm not really familiar with what the standard says, I can't comment on that. But I can only tell you what I observed in other HTTP servers and it appears that most convert a %3F into a question mark some time before sending the request to the classloader or to the filter that looks for the file. My current problem is actually limited to a specific area and I think taking a calculated risk and deviating slightly from the standard (if that's what it is), would not be the worst of all options. However, I would be interested in finding out what exactly the desired behavior for the final version of Tomcat 4.0 is. Speaking of which, is there a target release date yet? Klaus Sonnenleiter At 10:47 AM 4/13/01 -0700, you wrote: On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Craig, I looked at HttpRequestImpl. Would it be safe to manipulate the URI in a call to setRequestURI before it sets the instance variable requestURI? It seems like this gets called the moment a request is made - this way, the encoded characters could be transformed to their unencoded equivalents before the parameter list is parsed and the classloader gets called. Klaus The key thing to remember is a spec requirement that request.getRequestURI() must return the original request URI *without* decoding. The values returned by request.getServletPath() and request.getPathInfo(), on the other hand, are decoded first. Therefore, if you manipulate the request URI value in setRequestURI(), we'd need to make sure that we save an unmanipulated version somewhere as well. The deeper issue, though, is the portability of what you are proposing (across servlet containers) would be. As I understand it, you would like the %3f character to be interpreted as a "?" character so that the stuff after it is understood as part of the query string. That seems (to me) a questionable practice -- the reason you would use a %3f encoding in the first place is so that you could treat a question mark as a regular data character, instead of being a significant delimiter. If you decode first and then find that the "?" is significant, how would you ever include a question mark as part of the data value for a query string parameter (for example)? NOTE: There also needs to be a little more work in this area with respect to path parameters (;xxx stuff, which is how the session id is transmitted). This is being discussed in the expert group, and will probably require some minor changes in this area of Tomcat 4. Craig At 09:34 AM 4/13/01 -0700, you wrote: On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Oops, I guess I should have mentioned that I'm using the 4.0 version. Do you happen to know where the RequestImpl or equivalent class is in catalina? (I checked org.apache.catalina.core.* without success). The base class is org.apache.catalina.connector.HttpRequestBase. The 1.1 connector subclasses this as org.apache.catalina.connector.http.HttpRequestImpl. Craig
Re: %3F Problem
On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Craig, I looked at HttpRequestImpl. Would it be safe to manipulate the URI in a call to setRequestURI before it sets the instance variable requestURI? It seems like this gets called the moment a request is made - this way, the encoded characters could be transformed to their unencoded equivalents before the parameter list is parsed and the classloader gets called. Klaus The key thing to remember is a spec requirement that request.getRequestURI() must return the original request URI *without* decoding. The values returned by request.getServletPath() and request.getPathInfo(), on the other hand, are decoded first. Therefore, if you manipulate the request URI value in setRequestURI(), we'd need to make sure that we save an unmanipulated version somewhere as well. The deeper issue, though, is the portability of what you are proposing (across servlet containers) would be. As I understand it, you would like the %3f character to be interpreted as a "?" character so that the stuff after it is understood as part of the query string. That seems (to me) a questionable practice -- the reason you would use a %3f encoding in the first place is so that you could treat a question mark as a regular data character, instead of being a significant delimiter. If you decode first and then find that the "?" is significant, how would you ever include a question mark as part of the data value for a query string parameter (for example)? NOTE: There also needs to be a little more work in this area with respect to path parameters (;xxx stuff, which is how the session id is transmitted). This is being discussed in the expert group, and will probably require some minor changes in this area of Tomcat 4. '?' shouldn't be encoded in the first place as it's a reserved character (just like you should never encode '/' in the path). If it's encoded, I don't think it should be interpreted as the delimiter for the query section of the URL. So IMO the current TC behavior is the right one. The RFC for URIs is http://www.ietf.org/rfc/rfc2396.txt Remy
Re: %3F Problem
Remy, Craig, Yes, you're right. I read the specs and apparently the TC way of doing things is precisely the way it's written in the standard. However, that still doesn't fix my problem except if I want to carry along my hacked version forever. Here's what I'm trying to achieve: I currently have Tomcat proxy requests to underlying applications. When proxying applets however, I'm running into trouble since I need to pass parameters to the proxy from the URI which in this case is embedded in an APPLET tag and gets cut at the question mark by the browser unless it's escaped. A properly behaving Tomcat will not be able to find the right servlet. So, is there any way to intercept the first call to the URI parser, determine whether this is one of my previously encoded URIs and replace the escaped character if it is? Klaus At 10:55 AM 4/13/01 -0700, you wrote: On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Craig, I looked at HttpRequestImpl. Would it be safe to manipulate the URI in a call to setRequestURI before it sets the instance variable requestURI? It seems like this gets called the moment a request is made - this way, the encoded characters could be transformed to their unencoded equivalents before the parameter list is parsed and the classloader gets called. Klaus The key thing to remember is a spec requirement that request.getRequestURI() must return the original request URI *without* decoding. The values returned by request.getServletPath() and request.getPathInfo(), on the other hand, are decoded first. Therefore, if you manipulate the request URI value in setRequestURI(), we'd need to make sure that we save an unmanipulated version somewhere as well. The deeper issue, though, is the portability of what you are proposing (across servlet containers) would be. As I understand it, you would like the %3f character to be interpreted as a "?" character so that the stuff after it is understood as part of the query string. That seems (to me) a questionable practice -- the reason you would use a %3f encoding in the first place is so that you could treat a question mark as a regular data character, instead of being a significant delimiter. If you decode first and then find that the "?" is significant, how would you ever include a question mark as part of the data value for a query string parameter (for example)? NOTE: There also needs to be a little more work in this area with respect to path parameters (;xxx stuff, which is how the session id is transmitted). This is being discussed in the expert group, and will probably require some minor changes in this area of Tomcat 4. '?' shouldn't be encoded in the first place as it's a reserved character (just like you should never encode '/' in the path). If it's encoded, I don't think it should be interpreted as the delimiter for the query section of the URL. So IMO the current TC behavior is the right one. The RFC for URIs is http://www.ietf.org/rfc/rfc2396.txt Remy
Pier
Hi all, I just got off the phone with Pier. He asked me to tell you that he is in Italy right now and his net connection sucks so he is somewhat unavailable. He will be back in London on Monday and will be back online then. Thanks! -jon
Re: %3F Problem
On Fri, 13 Apr 2001, Klaus Sonnenleiter wrote: Craig, since I'm not really familiar with what the standard says, I can't comment on that. But I can only tell you what I observed in other HTTP servers and it appears that most convert a %3F into a question mark some time before sending the request to the classloader or to the filter that looks for the file. My current problem is actually limited to a specific area and I think taking a calculated risk and deviating slightly from the standard (if that's what it is), would not be the worst of all options. Remy has pointed out the RFCs for interpreting URIs. However, I would be interested in finding out what exactly the desired behavior for the final version of Tomcat 4.0 is. The controlling authority for Tomcat 4.0 behavior is the Servlet 2.3 and JSP 1.2 specifications (both in "Proposed Final Draft" status) at: http://java.sun.com/products/servlet/download.html http://java.sun.com/products/jsp/download.html Both specs contain references to other specs they rely on as well. Basically, the spec defines what a web application developer can assume is portable across servlet containers. There are lots of features in Tomcat 4.0 that go beyond the spec, which are basically defined by the code contributions that are made. But the specifics of the behavior you are talking about here seems to be pretty clearly defined in the relevant specifications. Speaking of which, is there a target release date yet? It doesn't make much sense to have Tomcat 4.0 go final until the specs do (there have in fact been some minor changes -- and some clarifications are still being discussed in the JSR-053 expert group that produced these specs even as I type). Therefore, we'll continue to release "betas", with increasing functionality and performance along with bug fixes, until then. Klaus Sonnenleiter Craig
Re: %3F Problem
So, is there any way to intercept the first call to the URI parser, determine whether this is one of my previously encoded URIs and replace the escaped character if it is? Never mind, I just answered that for myself (must have been half asleep when I asked g).
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm JDBCRealm.java
craigmcc01/04/13 12:57:45
Modified:catalina/src/share/org/apache/catalina/realm JDBCRealm.java
Log:
Refactor so that this class can be easily specialized by subclassing (including
the creation of an implementation that uses a connection pool instead).
Revision ChangesPath
1.13 +104 -57
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java
Index: JDBCRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- JDBCRealm.java2001/04/11 01:46:09 1.12
+++ JDBCRealm.java2001/04/13 19:57:45 1.13
@@ -86,14 +86,14 @@
* See the JDBCRealm.howto for more details on how to set up the database and
* for configuration options.
*
- * TODO:
- *- Make sure no bad chars can get in and trick the auth and hasrole
- *- Use a database connection pool for faster simultaneous access
+ * pstrongTODO/strong - Support connection pooling (including message
+ * format objects) so that codeauthenticate()/code does not have to be
+ * synchronized./p
*
* @author Craig R. McClanahan
* @author Carson McDonald
* @author Ignacio Ortega
- * @version $Revision: 1.12 $ $Date: 2001/04/11 01:46:09 $
+ * @version $Revision: 1.13 $ $Date: 2001/04/13 19:57:45 $
*/
public class JDBCRealm
@@ -307,57 +307,28 @@
* event is also logged, and the connection will be closed so that
* a subsequent request will automatically re-open it.
*
- * strongIMPLEMENTATION NOTE/strong - This method is synchronized
- * because we are sharing a single connection (and its associated
- * prepared statements) across all request threads.
- *
* @param username Username of the Principal to look up
* @param credentials Password or other credentials to use in
* authenticating this username
*/
-public synchronized Principal authenticate(String username,
-String credentials) {
+public Principal authenticate(String username, String credentials) {
+
+Connection dbConnection = null;
try {
-// Ensure that our database connection is open
-open();
+// Ensure that we have an open database connection
+dbConnection = open();
-// Look up the user's credentials
-String dbCredentials = null;
-PreparedStatement stmt = credentials(username);
-ResultSet rs = stmt.executeQuery();
-while (rs.next()) {
-dbCredentials = rs.getString(1).trim();
-}
-rs.close();
-if (dbCredentials == null)
-return (null);
+// Acquire a Principal object for this user
+Principal principal = authenticate(dbConnection,
+ username, credentials);
-// Validate the user's credentials
-if (digest(credentials).equals(dbCredentials)) {
-if (debug = 2)
-log(sm.getString("jdbcRealm.authenticateSuccess",
- username));
-} else {
-if (debug = 2)
-log(sm.getString("jdbcRealm.authenticateFailure",
- username));
-return (null);
-}
-
-// Accumulate the user's roles
-ArrayList list = new ArrayList();
-stmt = roles(username);
-rs = stmt.executeQuery();
-while (rs.next()) {
-list.add(rs.getString(1).trim());
-}
-rs.close();
-dbConnection.commit();
+// Release the database connection we just used
+release(dbConnection);
-// Create and return a suitable Principal for this user
-return (new GenericPrincipal(this, username, credentials, list));
+// Return the Principal (if any)
+return (principal);
} catch (SQLException e) {
@@ -365,7 +336,8 @@
log(sm.getString("jdbcRealm.exception"), e);
// Close the connection so that it gets reopened next time
-close();
+if (dbConnection != null)
+close(dbConnection);
// Return "not authenticated" for this request
return (null);
@@ -382,10 +354,68 @@
/**
- * Close any database connection that is currently open.
+ * Return the Principal associated with the specified username and
+ * credentials, if there is
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets SsiInvokerServlet.java
amyroh 01/04/13 14:00:38
Modified:catalina/src/share/org/apache/catalina/servlets
SsiInvokerServlet.java
Log:
Bug 1272 Fixed -- submitted by Vanitha Venkatraman.
Takes care of single quotes inside of double quotes in errmsg.
Added handling of null parameters so that it displays an error message instead of
throwing ServletException.
Revision ChangesPath
1.5 +15 -12
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java
Index: SsiInvokerServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SsiInvokerServlet.java2001/04/03 22:39:32 1.4
+++ SsiInvokerServlet.java2001/04/13 21:00:37 1.5
@@ -1,8 +1,8 @@
/*
* SsiInvokerServlet.java
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
1.4 2001/04/03 22:39:32 amyroh Exp $
- * $Revision: 1.4 $
- * $Date: 2001/04/03 22:39:32 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/SsiInvokerServlet.java,v
1.5 2001/04/13 21:00:37 amyroh Exp $
+ * $Revision: 1.5 $
+ * $Date: 2001/04/13 21:00:37 $
*
*
*
@@ -98,7 +98,8 @@
* Mapped to a path from within web.xml.
*
* @author Bip Thelin
- * @version $Revision: 1.4 $, $Date: 2001/04/03 22:39:32 $
+ * @author Amy Roh
+ * @version $Revision: 1.5 $, $Date: 2001/04/13 21:00:37 $
*/
public final class SsiInvokerServlet extends HttpServlet {
/** Debug level for this servlet. */
@@ -290,6 +291,12 @@
byteCmp(unparsed, bIdx, bEnd)) {
inside = false;
bIdx += bEnd.length;
+try {
+strCmd = parseCmd(command);
+} catch (IndexOutOfBoundsException ex) {
+out.write(ssiMediator.getError());
+continue;
+}
strCmd = parseCmd(command);
strParamType = parseParamType(command, strCmd.length());
strParam = parseParam(command, strCmd.length());
@@ -367,9 +374,8 @@
quotes=0;
while(bIdx cmd.length()quotes!=2) {
- if(cmd.charAt(bIdx)=='"'||
-cmd.charAt(bIdx)=='\'')
- quotes++;
+ if(cmd.charAt(bIdx)=='"')
+ quotes++;
bIdx++;
}
@@ -402,8 +408,7 @@
while(bIdx cmd.length()) {
if(!inside) {
while(bIdx cmd.length()
- cmd.charAt(bIdx)!='"'
- cmd.charAt(bIdx)!='\'')
+ cmd.charAt(bIdx)!='"')
bIdx++;
if(bIdx=cmd.length())
@@ -411,9 +416,7 @@
inside=!inside;
} else {
- while(bIdx cmd.length()
- cmd.charAt(bIdx)!='"'
- cmd.charAt(bIdx)!='\'') {
+ while(bIdx cmd.length() cmd.charAt(bIdx)!='"') {
retBuf.append(cmd.charAt(bIdx));
bIdx++;
}
is this a BUG at class loading from jarfiles
Situation: I have several webapplications that using the same jar filename. webapps/app.new/WEB-INF/lib/javaserver.jar webapps/app.stable/WEB-INF/lib/javaserver.jar webapps/app.test/WEB-INF/lib/javaserver.jar these jarfiles are different Problem: if i access the webapplication with http://localhost:8080/app.stable/xxx.jsp the classloader will use the jarfile located in webapps/app.new/WEB-INF/javaserver.jar if i delete the javaserver.jar in webapps/app.stable/WEB-INF/lib/ then i get an noclassdevfound exception if i delete the javaserver.jar in webapps/app.new/WEB-INF/lib/ then it works if i rename all javaserver.jar files to different names like this webapps/app.new/WEB-INF/lib/javaserver1.jar webapps/app.stable/WEB-INF/lib/javaserver2.jar webapps/app.test/WEB-INF/lib/javaserver3.jar then all applications will work for me it seems that the classloader loads the class from the javaserver.jar file it found first in the filesystem
Re: is this a BUG at class loading from jarfiles
On Fri, 13 Apr 2001, Mario Koch wrote: Situation: I have several webapplications that using the same jar filename. webapps/app.new/WEB-INF/lib/javaserver.jar webapps/app.stable/WEB-INF/lib/javaserver.jar webapps/app.test/WEB-INF/lib/javaserver.jar these jarfiles are different Is this Tomcat 4.0-beta-3? If so, this bug has already been fixed, and you should grab the most recent nightly distribution. Otherwise, please include the version number and submit a bug report to: http://nagoya.apache.org/bugzilla/ Craig McClanahan
Jasper
Hi, While Mel is working on the JspServlet proposal, I thought it would be a good idea to send my notes on jasper. I looked at both "branches" of jasper, with the idea of trying to merge them while preserving each "personality". As I expected, most of the code is still common, with only few variations that can be resolved by modularization. Unfortunately, the code requires some work in order to implement most of the optimizations I have in mind and before we can merge them. Some ideas are available at http://nagoya.apache.org/~costin/jasper.txt I don't know how much free time I'll have for that before 3.3 beta, but there are a lot of cool things that can be done in jasper ( and not only performance enhancements ). Costin
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm JNDIRealm.java LocalStrings.properties
craigmcc01/04/13 14:18:43
Modified:catalina/src/share/org/apache/catalina/realm
LocalStrings.properties
Added: catalina/src/share/org/apache/catalina/realm JNDIRealm.java
Log:
Initial version of a Realm implementation for Tomcat 4.0 that utilizes a
directory server (accessed via JNDI) to perform user authentication and
access control for container-managed security. This code is based in
large part on the proposed code (on TOMCAT-DEV) by John Holman, with some
additions and refactoring by me.
Use of this realm would be configured in "conf/server.xml" by an entry
like this to connect to an LDAP server on the same host that Tomcat is
running on:
Realm className="org.apache.catalina.realm.JNDIRealm"
connectionName="admin-username"
connectionPassword="admin-password"
connectionURL="ldap://localhost:389"
userPattern="cn={0},dc=mycompany,dc=com"
userPassword="userPassword"
roleBase="dc=groups,dc=mycompany,dc=com"
roleName="cn"
roleSearch="(|(uniqueMember={0})(member={0}))"
roleSubtree="false"
/
TODO: Update the configuration documentation to describe the above.
TODO: Support an operational mode where the Realm attempts to bind to the
directory server using the user's username and password (instead of a
system administrator username and password). This is a different enough
style that it probably should be a separate implementation class.
TODO: Support connection pooling (for both this and JDBCRealm) so that
the authenticate() method does not have to be synchronized.
Revision ChangesPath
1.4 +6 -1
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/LocalStrings.properties,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- LocalStrings.properties 2001/04/11 01:46:09 1.3
+++ LocalStrings.properties 2001/04/13 21:18:42 1.4
@@ -1,4 +1,4 @@
-# $Id: LocalStrings.properties,v 1.3 2001/04/11 01:46:09 craigmcc Exp $
+# $Id: LocalStrings.properties,v 1.4 2001/04/13 21:18:42 craigmcc Exp $
# language
@@ -9,6 +9,11 @@
jdbcRealm.close=Exception closing database connection
jdbcRealm.exception=Exception performing authentication
jdbcRealm.open=Exception opening database connection
+jndiRealm.authenticateFailure=Username {0} NOT successfully authenticated
+jndiRealm.authenticateSuccess=Username {0} successfully authenticated
+jndiRealm.close=Exception closing directory server connection
+jndiRealm.exception=Exception performing authentication
+jndiRealm.open=Exception opening directory server connection
memoryRealm.authenticateFailure=Username {0} NOT successfully authenticated
memoryRealm.authenticateSuccess=Username {0} successfully authenticated
memoryRealm.loadExist=Memory database file {0} cannot be read
1.1
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JNDIRealm.java
Index: JNDIRealm.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler DelegatingListener.java JspParseEventListener.java Parser.java XmlOutputter.java
horwat 01/04/13 14:51:34
Modified:jasper/src/share/org/apache/jasper/compiler
DelegatingListener.java JspParseEventListener.java
Parser.java XmlOutputter.java
Log:
Fixed mapping between JSP and XML syntax according to Section 5.3 of JSP 1.2
specification:
- tag library namespaces are now added to root element instead of using the
"directive.taglib" syntax
- fixed character data handling
Bugzilla #1221
Revision ChangesPath
1.7 +6 -4
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/DelegatingListener.java
Index: DelegatingListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/DelegatingListener.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- DelegatingListener.java 2000/12/05 11:05:19 1.6
+++ DelegatingListener.java 2001/04/13 21:51:33 1.7
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/DelegatingListener.java,v
1.6 2000/12/05 11:05:19 pierred Exp $
- * $Revision: 1.6 $
- * $Date: 2000/12/05 11:05:19 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/DelegatingListener.java,v
1.7 2001/04/13 21:51:33 horwat Exp $
+ * $Revision: 1.7 $
+ * $Date: 2001/04/13 21:51:33 $
*
*
*
@@ -238,6 +238,8 @@
throws JasperException {}
public void handleJspCdata(Mark start, Mark stop, char[] data)
-throws JasperException {}
+throws JasperException {
+delegate.handleJspCdata(start, stop, data);
+}
}
1.25 +9 -5
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Index: JspParseEventListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- JspParseEventListener.java2001/04/09 23:38:12 1.24
+++ JspParseEventListener.java2001/04/13 21:51:33 1.25
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.24 2001/04/09 23:38:12 horwat Exp $
- * $Revision: 1.24 $
- * $Date: 2001/04/09 23:38:12 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.25 2001/04/13 21:51:33 horwat Exp $
+ * $Revision: 1.25 $
+ * $Date: 2001/04/13 21:51:33 $
*
*
*
@@ -752,9 +752,12 @@
String uri = attrs.getValue("uri");
String prefix = attrs.getValue("prefix");
processTaglibDirective(uri, prefix);
+
+//Add xmlns to root element for each taglib
+xo.addRootNamespaces(prefix, uri);
}
- if (directive.equals("include")) {
+ else if (directive.equals("include")) {
String file = attrs.getValue("file");
if (file == null)
throw new CompileException(start,
@@ -781,7 +784,8 @@
ex.getMessage());
}
}
- if (!directive.equals("include")) {
+
+ else if (!directive.equals("include")) {
xo.append("jsp:directive." + directive, attrs);
}
}
1.8 +4 -2
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Parser.java 2001/02/09 00:19:19 1.7
+++ Parser.java 2001/04/13 21:51:34 1.8
@@ -1063,8 +1063,10 @@
void flushCharData(Mark start, Mark stop) throws JasperException {
char[] array = caw.toCharArray();
-if (array.length != 0) // Avoid unnecessary out.write("") statements...
-listener.handleCharData(start, stop, caw.toCharArray());
+// Avoid unnecessary out.write("") statements...
+if (array.length != 0) {
+listener.handleJspCdata(start, stop, caw.toCharArray());
+}
caw = new CharArrayWriter();
}
1.8 +15 -4
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java
Index: XmlOutputter.java
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler XmlOutputter.java
horwat 01/04/13 14:54:41
Modified:jasper/src/share/org/apache/jasper/compiler
XmlOutputter.java
Log:
OopsRemove my debug statement.
Revision ChangesPath
1.9 +3 -5
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java
Index: XmlOutputter.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- XmlOutputter.java 2001/04/13 21:51:34 1.8
+++ XmlOutputter.java 2001/04/13 21:54:40 1.9
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java,v
1.8 2001/04/13 21:51:34 horwat Exp $
- * $Revision: 1.8 $
- * $Date: 2001/04/13 21:51:34 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/XmlOutputter.java,v
1.9 2001/04/13 21:54:40 horwat Exp $
+ * $Revision: 1.9 $
+ * $Date: 2001/04/13 21:54:40 $
*
*
*
@@ -238,8 +238,6 @@
buff.append("/jsp:root");
InputStream is =
new ByteArrayInputStream(buff.toString().getBytes());
-//DELETE
-System.out.println("getPageData: \n" + buff.toString());
PageData pageData = new PageDataImpl(is);
return pageData;
}
cvs commit: jakarta-tomcat/src/etc tomcat.policy
glenn 01/04/13 15:09:06
Modified:src/etc Tag: tomcat_32 tomcat.policy
Log:
Fix PropertyPermission type, add a default grant
Revision ChangesPath
No revision
No revision
1.5.2.2 +27 -5 jakarta-tomcat/src/etc/tomcat.policy
Index: tomcat.policy
===
RCS file: /home/cvs/jakarta-tomcat/src/etc/tomcat.policy,v
retrieving revision 1.5.2.1
retrieving revision 1.5.2.2
diff -u -r1.5.2.1 -r1.5.2.2
--- tomcat.policy 2000/12/28 22:11:00 1.5.2.1
+++ tomcat.policy 2001/04/13 22:09:06 1.5.2.2
@@ -2,16 +2,16 @@
// javac
grant codeBase "file:${java.home}/../lib/-" {
- permission java.security.AllPermission;
+permission java.security.AllPermission;
};
// Tomcat gets all permissions
grant codeBase "file:${tomcat.home}/lib/-" {
- permission java.security.AllPermission;
+permission java.security.AllPermission;
};
grant codeBase "file:${tomcat.home}/classes/-" {
- permission java.security.AllPermission;
+permission java.security.AllPermission;
};
// Example webapp policy
@@ -19,7 +19,29 @@
// line.separator, path.separator, and file.separator PropertyPermissions.
// Any permissions you grant here are in addition to the default.
grant codeBase "file:${tomcat.home}/webapps/examples" {
- // Allow the example web application to read all java properties
- permission java.util.ProperyPermission "*", "read";
+// Allow the example web application to read all java properties
+permission java.util.PropertyPermission "*", "read";
};
+grant {
+// OS Specific properties to allow read access
+permission java.util.PropertyPermission "os.name", "read";
+permission java.util.PropertyPermission "os.version", "read";
+permission java.util.PropertyPermission "os.arch", "read";
+
+// JVM properties to allow read access
+permission java.util.PropertyPermission "java.version", "read";
+permission java.util.PropertyPermission "java.vendor", "read";
+permission java.util.PropertyPermission "java.vendor.url", "read";
+permission java.util.PropertyPermission "java.class.version", "read";
+permission java.util.PropertyPermission "java.specification.version", "read";
+permission java.util.PropertyPermission "java.specification.vendor", "read";
+permission java.util.PropertyPermission "java.specification.name", "read";
+
+permission java.util.PropertyPermission "java.vm.specification.version", "read";
+permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
+permission java.util.PropertyPermission "java.vm.specification.name", "read";
+permission java.util.PropertyPermission "java.vm.version", "read";
+permission java.util.PropertyPermission "java.vm.vendor", "read";
+permission java.util.PropertyPermission "java.vm.name", "read";
+};
Tomcat 3.2.2 B3 tests with Java SecurityManager
I have tested Tomcat 3.2.2 B3 with and without the Java SecurityManager on a Solaris x86 system using J2SE 1.3. I found one minor problem in the tomcat.policy file, after fixing that all watchdog test were OK. I committed the changes to the tomcat.policy file. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: JDBCStore package for Tomcat 4.x
"Craig R. McClanahan" wrote: [...] - Would it be possible to flesh out the rest of the JavaDoc comments? I would like us to maintain the high quality level of JavaDocs that Tomcat 4 is known for :-) Done. - Would it be possible to parameterize the SQL statements used to access the database? The idea would be that we can adapt to different table and column names (like JDBCRealm does on the authentication side). Attatched is a slightly refactored JDBCStore with a "stub implementation" of a Connection pooled implementation. However before I change to much regarding specifying columns for the table I want to have som input on the following things. As it is implemented now everything is saved as a Blob so if you wan't to check if the session is invalid or is expired you have to retrive all data and iterate through every blob and make them into a session and THEN see if they are valid or not. I would like to propose that we save additional data in the database. The table would then look something like following: TABLE: [int ID] The ID for this session [boolean ISVALID] True if this session is valid [int MAXINACTIVE] The Max inactive attribute [Blob SESSION] The session object Then you could have a StoredProcedure if you want to that checks for timedout sessions and delete/invalidate them. The StoreProcedure way of doing is of course not the default behavior. I can now check every session for validity in the select query without having to retrieve the data. Thoughts? ..bip /* * JDBCStore.java * $Header$ * $Revision$ * $Date$ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * "This product includes software developed by the *Apache Software Foundation (http://www.apache.org/)." *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software *Foundation" must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called "Apache" *nor may "Apache" appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * * [Additional notices, if required by prior licensing conditions] * */ package org.apache.catalina.session; import java.beans.PropertyChangeListener; import java.beans.PropertyChangeSupport; import java.io.InputStream; import java.io.OutputStream; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.IOException; import java.io.InputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.io.ObjectStreamClass; import java.sql.Connection; import java.sql.DriverManager; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.SQLException;
Re: Tomcat 3.2.2 B3 tests with Java SecurityManager
On Fri, 13 Apr 2001, Glenn Nielsen wrote: I have tested Tomcat 3.2.2 B3 with and without the Java SecurityManager on a Solaris x86 system using J2SE 1.3. I found one minor problem in the tomcat.policy file, after fixing that all watchdog test were OK. I committed the changes to the tomcat.policy file. Great. Thanks Glenn ! BTW, I was thinking about the original proposal you made, with permissions specified in server.xml. Right now it would be quite easy to do a very clean implementation for that - a PermissionInterceptor that could be set per context. What I would like is to go back to setting everything in server.xml/app-foo.xml so later on an admin page could edit all properties, including permissions. In other words, an admin page that would edit generic modules properties would work with no change for permissions. Another argument is to allow other, non-file based configuration systems - like LDAP. Right now the policy is "special", it uses a different file format. ( I know, I know, I spent a lot of time arguing the reverse of what I'm saying now :-) Costin
cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml
craigmcc01/04/13 17:03:18
Modified:tester/src/bin tester.xml
tester/web/WEB-INF web.xml
Added: tester/src/tester/org/apache/tester ErrorPage05.java
ErrorPage06.java
tester/web ErrorPage06.html ErrorPage06.jsp
Log:
Add additional tests of the error-page mechanism to ensure that
RuntimeException errors thrown by a servlet are also handled correctly,
and that an error page handler can be any of a servlet, a JSP page, and an
HTML page.
Revision ChangesPath
1.28 +35 -2 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- tester.xml2001/04/11 04:31:07 1.27
+++ tester.xml2001/04/14 00:03:17 1.28
@@ -202,7 +202,6 @@
request="${context.path}/ErrorPage01" debug="${debug}"
outContent="ErrorPage02 PASSED"/
-
tester host="${host}" port="${port}" protocol="${protocol}"
request="${context.path}/WrappedErrorPage01" debug="${debug}"
outContent="ErrorPage02 PASSED"/
@@ -214,11 +213,45 @@
request="${context.path}/ErrorPage03" debug="${debug}"
outContent="ErrorPage04 PASSED"/
-
tester host="${host}" port="${port}" protocol="${protocol}"
request="${context.path}/WrappedErrorPage03" debug="${debug}"
outContent="ErrorPage04 PASSED"/
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/ErrorPage05?type=Arithmetic"
+ debug="${debug}"
+ status="200"
+ outContent="ErrorPage06 PASSED - SERVLET"/
+
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/WrappedErrorPage05?type=Arithmetic"
+ debug="${debug}"
+ status="200"
+ outContent="ErrorPage06 PASSED - SERVLET"/
+
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/ErrorPage05?type=Array"
+ debug="${debug}"
+ status="200"
+ outContent="ErrorPage06 PASSED - JSP"/
+
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/WrappedErrorPage05?type=Array"
+ debug="${debug}"
+ status="200"
+ outContent="ErrorPage06 PASSED - JSP"/
+
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/ErrorPage05?type=Number"
+ debug="${debug}"
+ status="200"
+ outContent="ErrorPage06 PASSED - HTML"/
+
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="${context.path}/WrappedErrorPage05?type=Number"
+ debug="${debug}"
+ status="200"
+ outContent="ErrorPage06 PASSED - HTML"/
/target
1.1
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/ErrorPage05.java
Index: ErrorPage05.java
===
/* = *
* *
* The Apache Software License, Version 1.1 *
* *
* Copyright (c) 1999, 2000, 2001 The Apache Software Foundation. *
* All rights reserved.*
* *
* = *
* *
* Redistribution and use in source and binary forms, with or without modi- *
* fication, are permitted provided that the following conditions are met: *
* *
* 1. Redistributions of source code must retain the above copyright notice *
*notice, this list of conditions and the following disclaimer. *
* *
* 2. Redistributions in binary form must reproduce the above copyright *
*notice, this list of conditions and the following disclaimer in the *
*documentation and/or other materials provided with the distribution. *
* *
* 3. The end-user documentation included with the redistribution, if any, *
*must include the following acknowlegement:
