Help on Tomcat
Hi, im running Tomcat 3.2.1 with Apache on Linux box i have replaced mod_jserv.so with tomcat's mod_jk.so for this configuration to work i need to run tomcat manually from console using the scripts and then start apache only then the JSP Engine starts working. Is there any way of starting tomcat Automatically the way JServ starts up by ApJServManual off command ? also to make the in-process system work, one needs to configure JNI in the distribution connector for WIN32 jni_connector.dll is available ..what about linux ? can this JNI mode work with APACHE-LINUX ? the in-process-howto talks only about win32 version, can i find any info on other platforms ? Regards and Thanks in Advance Deep Feel the pulse of the stock market on the tip of your finger Online Investments at http://www.icicidirect.com.
Q: Http authentication
Hi, I'm developing a java servlet application using tomcat ad apache web server under linux. The application is located in a reserved area of the website where the request are authenticated by basic authentication of Apache. Problem: since getRemoteUser returns always null, I haven't found a method to know the remote user name/id. I read in other messages of this list that actual implementation of tomcat does not manage this security feature -( but I would be surprised if does not exists any method to "connect" the web server authentication and the servlet engine. I supposed two scenarios: 1 - Apache make the basic authentication, and tells to the servlet who the authenticated user is 2 - (very, very better) Apache delegates a servlet for the authentication of an area... this would be the best solution (for this and other problems), but I'm pessimist Tnx Marco
Re: [RFC] Distributed sessions in Catalina
Craig R. McClanahan typed the following on 09:19 AM 12/26/2000 -0800 I continue to believe, though, that we should strive to agree on a high level functional requirements document before diving too far down into the "how to do it" details. OK, I can update my original RFC so it can be checked into CVS. What else should go into it, any suggestions for structure, etc.? A web application declares that it supports being run in a multiple-JVM container by including the distributable/ element in the deployment descriptor. If this element is not included, the container *must* run that particular app in one and only one container. This applies whether sessions are being used or not -- thus, the load balancing model that Apache JServ uses (for example) would not conform. Ideally this can be enforced in a DistributedManager class, so Store implementations won't have to worry about it. Kief --- Kief Morris Director of Technology bitBull Ltd. http://www.bitBull.com phone +44 020 7598 9938 fax +44 020 7460 4081
[PATCH PROPOSAL]: Catalina 4.0: FileStore, PersistentManager
OK, here's a start on the code for FileStore and a persistent session Manager
class. The attached patches and new class file basically duplicate the functionality
of the current StandardManager class, but the code for loading and unloading
sessions to disk has been moved to FileStore.
The following patches shouldn't affect default useage of Catalina. To try
them out, add the following to the server.xml Context section for the webapp
you want to use PersistentManager for:
Manager className="org.apache.catalina.session.PersistentManager"
debug="3"/
Store
Added setManager() and getManager() methods to give the Store
a reference to the Manager class which is using it.
To do:
I'm thinking about adding a clear() method to this, which will remove all
sessions from the Store.
FileStore
Implemented getSize(), keys(), load(), remove(), clear(), save(), and various
utility methods. Most of the code, especially for the serialization operations,
came from StandardManager.
Sessions are now saved one per file. This is less efficient for loading and
unloading all of the sessions at once, but will be better for the more interesting
functionality which PersistentManager will have.
To Do:
- Move the actual serialization code to a utility class.
- Iron out configuration with server.xml
PersistentManager
Currently this is a clone of StandardManager, but the load() and unload()
functionality has been changed to use a Store object to do the work.
To Do:
- Add code to manage swapping out of active but idle sessions to the Store.
LocalStrings
Added some messages for FileStore and PersistentManager
--- FileStore.java.orig Fri Aug 11 20:39:15 2000
+++ FileStore.java Wed Dec 27 09:57:13 2000
@@ -74,18 +74,27 @@
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
+import java.io.InputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
+import java.io.ObjectStreamClass;
import java.io.Serializable;
import java.util.Enumeration;
import java.util.Hashtable;
import java.util.Vector;
+import javax.servlet.ServletContext;
+import org.apache.catalina.Context;
+import org.apache.catalina.Globals;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.LifecycleListener;
+import org.apache.catalina.Loader;
+import org.apache.catalina.Logger;
+import org.apache.catalina.Manager;
import org.apache.catalina.Session;
import org.apache.catalina.Store;
+import org.apache.catalina.Container;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;
@@ -95,7 +104,6 @@
* a file per saved Session in a configured directory. Sessions that are
* saved are still subject to being expired based on inactivity.
*
- * @author Craig R. McClanahan
* @version $Revision: 1.1 $ $Date: 2000/08/11 23:39:15 $
*/
@@ -103,6 +111,14 @@
implements Lifecycle, Runnable, Store {
+// - Constants
+
+
+/**
+ * The extension to use for all serialized session filenames.
+ */
+private static final String FILE_EXT = ".session";
+
// - Instance Variables
@@ -116,7 +132,12 @@
/**
* The pathname of the directory in which Sessions are stored.
*/
-private String directoryPath = "./STORE";
+private String directoryPath = ".";
+
+/**
+ * A File representing the directory in which Sessions are stored.
+ */
+private File directoryFile = null;
/**
@@ -163,6 +184,18 @@
/**
+ * The Manager with which this FileStore is associated.
+ */
+protected Manager manager;
+
+
+/**
+ * The debugging detail level for this component.
+ */
+protected int debug = 0;
+
+
+/**
* Name to register for the background thread.
*/
private String threadName = "FileStore";
@@ -216,6 +249,7 @@
String oldDirectoryPath = this.directoryPath;
this.directoryPath = path;
+ this.directoryFile = null;
support.firePropertyChange("directoryPath", oldDirectoryPath,
this.directoryPath);
@@ -241,7 +275,16 @@
*/
public int getSize() throws IOException {
- return (0); // FIXME: getSize()
+ String[] files = getDirectoryFile().list();
+
+ // Figure out which files are sessions
+ int keycount = 0;
+ for (int i = 0; i files.length; i++) {
+ if (files[i].endsWith(FILE_EXT))
+ keycount++;
+ }
+
+ return (keycount);
}
@@ -270,7 +313,30 @@
*/
public String[] keys() throws IOException {
- return (new String[0]); // FIXME: keys()
+
realm always checked?
Quick question: why does Catalina check with the Realm implementation on every HTTP request, even after a successful authentication? Is it the responsibility of the Realm to handle caching and expiring of credentials? Seems to me that would lead to a good bit of replication of code among Realm implementations. Also, would there be any objection to my factoring out common functions from MemoryRealm, JDBCRealm and JAASRealm into an "AbstractRealm" helper class? There's a lot of cut-and-pasting to do when writing a Realm right now. I can post said class for review, since I am not a committer. --kd
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/context ErrorHandler.java
costin 00/12/27 09:02:06
Modified:src/share/org/apache/tomcat/context ErrorHandler.java
Log:
Fixed ErrorHandler - showDebugInfo was removed from ContextManager as
an "explicit" property. Larry - we can add it back, I just wanted to
test the setProperty mechanism.
The fix also allow contexts to override the setting in context manager -
you can set it now at context level.
What's interesting is that it does that without any special code in core -
any new attributes can be added to context and contextManager tags.
We should add properties to Context and ContextManager only if they are
very generic ( like "home" ).
Another method to do the same thing is to use per/context interceptors,
or settings on the interceptor ( for example showDebugInfo="true" on the
error handler ). This is better if the attribute is specific to a particular
module ( like session saving in a file ). For showDebugInfo, it's likely that
other modules will use it.
Revision ChangesPath
1.14 +41 -16
jakarta-tomcat/src/share/org/apache/tomcat/context/ErrorHandler.java
Index: ErrorHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/context/ErrorHandler.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ErrorHandler.java 2000/12/20 15:20:21 1.13
+++ ErrorHandler.java 2000/12/27 17:02:06 1.14
@@ -102,13 +102,32 @@
{
if( ctx.getHost() == null ctx.getPath().equals(""))
rootContext = ctx;
- ctx.addServlet( new ExceptionHandler(this));
- ctx.addServlet( new StatusHandler(this));
+ boolean showDebugInfo=true;
+ ContextManager cm=ctx.getContextManager();
+ String dI=cm.getProperty( "showDebugInfo" );
+ if( dI!=null ( dI.equalsIgnoreCase("no") ||
+ dI.equalsIgnoreCase("false"))) {
+ showDebugInfo=false;
+ }
+
+ // override with per/context setting
+ dI=ctx.getProperty( "showDebugInfo" );
+ if( dI!=null ( dI.equalsIgnoreCase("no") ||
+ dI.equalsIgnoreCase("false"))) {
+ showDebugInfo=false;
+ }
+ if( dI!=null ( dI.equalsIgnoreCase("yes") ||
+ dI.equalsIgnoreCase("true"))) {
+ showDebugInfo=true;
+ }
+
+ ctx.addServlet( new ExceptionHandler(this, showDebugInfo));
+ ctx.addServlet( new StatusHandler(this, showDebugInfo));
// Default status handlers
ctx.addServlet( new RedirectHandler(this));
ctx.addErrorPage( "302", "tomcat.redirectHandler");
- ctx.addServlet( new NotFoundHandler(this));
+ ctx.addServlet( new NotFoundHandler(this, showDebugInfo));
ctx.addErrorPage( "404", "tomcat.notFoundHandler");
}
@@ -330,11 +349,13 @@
static StringManager sm=StringManager.
getManager("org.apache.tomcat.resources");
int sbNote=0;
+boolean showDebugInfo=true;
-NotFoundHandler(BaseInterceptor bi) {
+NotFoundHandler(BaseInterceptor bi, boolean showDebugInfo) {
// setOrigin( Handler.ORIGIN_INTERNAL );
name="tomcat.notFoundHandler";
setModule(bi);
+ this.showDebugInfo=showDebugInfo;
}
public void doService(Request req, Response res)
@@ -376,7 +397,7 @@
.append( requestURI )
.append("\r\n");
- if ( null != requestURI contextM.isShowDebugInfo() ) {
+ if ( null != requestURI showDebugInfo ) {
buf.append("brbr\r\nb")
.append(sm.getString("defaulterrorpage.notfoundrequest"))
.append("/b ")
@@ -400,11 +421,13 @@
static StringManager sm=StringManager.
getManager("org.apache.tomcat.resources");
int sbNote=0;
-
-ExceptionHandler(BaseInterceptor bi) {
+boolean showDebugInfo=true;
+
+ExceptionHandler(BaseInterceptor bi, boolean showDebugInfo) {
// setOrigin( Handler.ORIGIN_INTERNAL );
name="tomcat.exceptionHandler";
setModule( bi );
+ this.showDebugInfo=showDebugInfo;
}
public void doService(Request req, Response res)
@@ -440,7 +463,7 @@
// only include head...body if reset was successful
if (bufReset) {
buf.append("headtitle");
- if( null != errorURI contextM.isShowDebugInfo() ) {
+ if( null != errorURI showDebugInfo ) {
buf.append(sm.getString("defaulterrorpage.includedservlet") )
.append(" ");
} else {
@@ -450,7 +473,7 @@
.append("/title/head\r\nbody\r\n");
}
buf.append("h1");
- if( null != errorURI contextM.isShowDebugInfo() ) {
+ if( null != errorURI showDebugInfo ) {
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup EmbededTomcat.java
costin 00/12/27 09:15:09
Modified:.build.xml
src/etc server.xml
src/facade22/org/apache/tomcat/facade ServletHandler.java
ServletInfo.java ServletInputStreamFacade.java
ServletWriterFacade.java
src/share/org/apache/tomcat/startup EmbededTomcat.java
Added: src/build manifest.facade22
src/facade22/org/apache/tomcat/facade JspInterceptor.java
LoadOnStartupInterceptor.java
Removed: src/facade22/org/apache/tomcat/modules/facade22
JspInterceptor.java LoadOnStartupInterceptor.java
Log:
- Changed class protection from "public" to "package" in facade.
- added a "Sealed" manifest for facade
- moved LoadOnStartup and JspInterceptor in the same package - they
need access to package methods ( are specific to the facade )
I read the "facade" package few times, I see no way to cast a facade to
the implementation object or to access any method except what the API
provides. More review is needed, and a class loader mechanism to double the
protection.
Trusted applications can still call getAttribute("org.apache.tomcat.request")
or getAttribute("org.apache.tomcat.context") to access the "internal"
objects.
Revision ChangesPath
1.98 +3 -1 jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -r1.97 -r1.98
--- build.xml 2000/12/25 04:43:15 1.97
+++ build.xml 2000/12/27 17:14:57 1.98
@@ -180,7 +180,9 @@
include name="org/apache/tomcat/facade/**"/
include name="org/apache/tomcat/modules/facade22/**"/
/javac
-jar jarfile="${tomcat.build}/lib/facade22.jar"
basedir="${tomcat.build}/classes"
+jar jarfile="${tomcat.build}/lib/facade22.jar"
+ basedir="${tomcat.build}/classes"
+ manifest="src/build/manifest.facade22"
include name="org/apache/tomcat/facade/**"/
include name="org/apache/tomcat/modules/facade22/**"/
/jar
1.1 jakarta-tomcat/src/build/manifest.facade22
Index: manifest.facade22
===
Manifest-Version: 1.0
Name: org/apache/tomcat/facade/
Sealed: true
1.55 +2 -2 jakarta-tomcat/src/etc/server.xml
Index: server.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/etc/server.xml,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -r1.54 -r1.55
--- server.xml2000/12/12 20:21:18 1.54
+++ server.xml2000/12/27 17:15:00 1.55
@@ -161,7 +161,7 @@
!-- "jsp" handler
--
RequestInterceptor
-className="org.apache.tomcat.modules.facade22.JspInterceptor"
+className="org.apache.tomcat.facade.JspInterceptor"
debug="0" /
!-- "default" handler - static files and dirs
@@ -226,7 +226,7 @@
!-- Loaded last since JSP's that load-on-startup use request handling --
ContextInterceptor
-className="org.apache.tomcat.modules.facade22.LoadOnStartupInterceptor"
/
+className="org.apache.tomcat.facade.LoadOnStartupInterceptor" /
!-- Loaded last since JSP's that load-on-startup use request handling --
RequestInterceptor
1.10 +1 -1
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletHandler.java
Index: ServletHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletHandler.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ServletHandler.java 2000/12/20 15:25:50 1.9
+++ ServletHandler.java 2000/12/27 17:15:03 1.10
@@ -85,7 +85,7 @@
* @author Harish Prabandham
* @author Costin Manolache
*/
-public final class ServletHandler extends Handler {
+final class ServletHandler extends Handler {
/**
* If init() fails or preInit() detects the handler is still
1.5 +8 -8
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletInfo.java
Index: ServletInfo.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletInfo.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ServletInfo.java 2000/12/27 07:18:46 1.4
+++ ServletInfo.java 2000/12/27 17:15:04 1.5
@@ -85,25 +85,25 @@
* @author Harish Prabandham
* @author [EMAIL
cvs commit: jakarta-tomcat/src/doc/appdev/sample build.bat
marcsaeg00/12/27 09:20:16 Modified:src/doc/appdev/sample Tag: tomcat_32 build.bat Log: The CP variable is being built up in three steps, but the second step didn't include %CP% so the results of the first step were lost. PR: 591 Submitted by: Terry Traub ( [EMAIL PROTECTED] ) Revision ChangesPath No revision No revision 1.3.2.3 +2 -2 jakarta-tomcat/src/doc/appdev/sample/build.bat Index: build.bat === RCS file: /home/cvs/jakarta-tomcat/src/doc/appdev/sample/build.bat,v retrieving revision 1.3.2.2 retrieving revision 1.3.2.3 diff -u -r1.3.2.2 -r1.3.2.3 --- build.bat 2000/11/27 22:45:57 1.3.2.2 +++ build.bat 2000/12/27 17:20:11 1.3.2.3 @@ -1,12 +1,12 @@ @echo off rem build.bat -- Build Script for the "Hello, World" Application -rem $Id: build.bat,v 1.3.2.2 2000/11/27 22:45:57 craigmcc Exp $ +rem $Id: build.bat,v 1.3.2.3 2000/12/27 17:20:11 marcsaeg Exp $ set _CP=%CP% rem Identify the custom class path components we need set CP=%TOMCAT_HOME%\lib\ant.jar;%TOMCAT_HOME%\lib\servlet.jar -set CP=%TOMCAT_HOME%\lib\jaxp.jar;%TOMCAT_HOME%\lib\parser.jar +set CP=%CP%;%TOMCAT_HOME%\lib\jaxp.jar;%TOMCAT_HOME%\lib\parser.jar set CP=%CP%;%JAVA_HOME%\lib\tools.jar rem Execute ANT to perform the requird build target
BugRat access
I need to mark a couple BugRat items as fixed but I don't have a login for the BugRat system. Who do I need to contact to get an account created? Thanks.
TC 4.0 vs. TC 3.x and division of labor
I've been following of the TC4.0/TC3.2/TC3.3 threads for a while in
silence, and wanted to make an observation.
The Tomcat project really has two major types of customers: those who
want an open source servlet container for their production needs
("conservatives"), and those interested in the state-of-the-art
("tinkerers"). The project has made the decision--by supporting both 3.x
and 4.x in parallel--to try to serve both (a good decision, since I think
there are plenty of people in each user group).
The values of the conservatives are
* stability
* lack of bugs
* a seamless install
* performance
The values of the tinkerers are
* compliance with the latest standards ("100% buzzword compliant")
* advanced features
* elegance
These two groups have very little in common, except this: both will
tolerate change so long as it's in the direction of their values. A
conservative will not argue with you about changing Tomcat 3.2 to 3.3 if
it's to make it faster, more stable, or less buggy. "More elegant" or
"more featureful" doesn't cut it, though, which is why I suspect there
will be little interest in Servlet 2.3 on top of 3.x (thus it's good for
it to be a "contrib" element, for the few who DO want such a combo).
I think so long as 3.3 is a move--as Costin says it is--toward a
better-factored, less-buggy version of 3.2, and all the changes taking
place are just moving around established, tested code, then it's a good
direction. I have consulting customers who may very well end their project
lifecycles still on servlet 2.1, old school or not!
So long as we keep in mind who's served by a change, and keep it
consistent with what that groups wants, I think we can safely move 3.x
through a fairly long arc. There seems to be enough interest in each
viewpoint to support 3.x and 4.x at once without bogging down the project.
regards,
kd
Re: FileStore
Kief Morris wrote: Craig R. McClanahan typed the following on 09:38 AM 12/26/2000 -0800 So far I'm looking to implement the FileStore class by cribbing code from StandardManager's load() and unload() methods, to store session data in individual files named with the session ID. I've also created a class called PersistentManager which will use this store. It might be possible to extract this code into a shared utility class if it is really reusable. Sounds reasonable. Would it be useful in areas other than sessions, e.g. for storing web application state? Hmm ... One of the things we haven't talked about yet is dealing with servlet context attributes, which is pretty much all the "web application state" information that is kept by the container itself, outside of user sessions. There might be a way to leverage technology like this for context attributes as well. I need to go back and read up on the spec requirements for distributed containers some more. The general idea was that a Manager implementation interested in supporting persistence or swapping of sessions would choose a Store implementation (see below for config stuff), and would then call the load() and save() methods on it whenever the Manager's policies so dictated. This could be after every request (as Shai proposed), at startup/shutdown only (replacing the primitive mechanism used in StandardManager today), or dynamically for swapping or session moving. What I'm thinking at the moment is to create PersistentManager, which will be configurable to set the different policies you suggest, so users can tweak it for their needs. The StandardManager could have its load() and unload() code stripped, so it provides a bare-bones implementation. Sounds good. I only added load/unload to the basic StandardManager because I needed "save sessions across restart" before I had time to build the rest of the persistence infrastructure. A separate DistributedManager class could then be implemented, probably sharing a fair amount of code with PersistentManager. * Create another level of nesting inside Manager called Store. This is probably better, because you can now configure the properties of the Store implementation using Store attributes. This sounds like the best approach. I'll start digging around into how to do this: if you can give me any pointers, good starting places, etc. I'd appreciate it. One issue: there are likely to be attributes specific to certain Store implementations. Namely, FileStore needs to have a directory to store its serialized sessions into, but this doesn't seem appropriate for the Store interface. How should this work? This actually works in a very slick fashion. (I didn't invent this, but I wish I had ;-). When XmlMapper is processing the server.xml file, it's primary job is to apply "rules" that match the nesting pattern of XML elements -- in our case, the pattern would be "Server/Service/Engine/Host/Context/Manager/Store". One of the rules we will set up is the "set properties" rule, which uses Java reflection APIs on the top object on the stack (which will be the Store instance you just created), and matches up XML attribute names with public JavaBeans property names, and calls all the matching setXxxx methods for you. The net result of this is that implementation classes like FileStore or JDBCStore or WhateverStore can have their own particular configuration properties, and nothing special has to be done to the configuration file processing code to accomodate this -- all you have to do is make sure you specify the right fully qualified class name. A consequence of this, of course, is that it is not possible to create a DTD that fully describes the valid contents of a server.xml file, but IMHO the tradeoff is well worth it. - The FileStore implementation I'm using needs to get access to the Container. That makes sense to me -- in fact, I cannot imagine a Store implementation that would not need this. It should be added to the official Store interface so that all implementations have to support it. A patch follows. If we use the second configuration approach, you can set up the configuration rules to call setManager() for you to establish this link, with an "set parent" rule, so that it happens for you automatically. Cool! Thanks, Kief --- Kief Morris Craig
Re: Tomcat session replicator
On Fri, 22 Dec 2000, Craig R. McClanahan wrote: "[EMAIL PROTECTED]" wrote: why not do iot in shared storage and implement SSI ? thats what the mod_jserv shm file was for...a shared hunk of disk store. -Ys- [EMAIL PROTECTED] This is certainly one valid approach. It works for cases where the servers are all on the same machine. But you still need an approach that works on a multiple machine environment as well. It would be worth someone taking the time to articulate proposed use cases, from which we can identify desired features. My bet is that we will end up wanting a variety of pluggable implementations with different functionality and performance characteristics. Craig theres no reason to have the shared disk store PER SERVER like mod_jserv. you simply distribute the data to all the servers which are in the shared pool. i've done that and thats how i implemented it. unfortunately ive signed an NDA so i cant distribute...but my point is that if i can do it im sure you guys can do it better. -Ys- [EMAIL PROTECTED]
Re: Tomcat session replicator
On Fri, 22 Dec 2000, Jason Brittain wrote: Craig R. McClanahan wrote: "[EMAIL PROTECTED]" wrote: why not do iot in shared storage and implement SSI ? thats what the mod_jserv shm file was for...a shared hunk of disk store. -Ys- [EMAIL PROTECTED] This is certainly one valid approach. It works for cases where the servers are all SNIP Comments? Suggestions? -- Jason Brittain do geographical load balancing too. servers closest to the user should be able to get the hit. thats one piece im missing in my SSI implementation. you can do it all in java. the w3c does it BTW for their webservers. -Ys- [EMAIL PROTECTED]
Re: BugRat access
I give people who are accepted committers to Jakarta admin access to BugRat. On Wed, 27 Dec 2000, Marc Saegesser wrote: I need to mark a couple BugRat items as fixed but I don't have a login for the BugRat system. Who do I need to contact to get an account created? Thanks. -- Nicolaus Bauman Software Engineer Simplexity Systems
Re: realm always checked?
"Kyle F. Downey" wrote: Quick question: why does Catalina check with the Realm implementation on every HTTP request, even after a successful authentication? Is it the responsibility of the Realm to handle caching and expiring of credentials? Seems to me that would lead to a good bit of replication of code among Realm implementations. If you are in a session, the authenticated principal is actually cached (in a private variable inside the Session object). If you are not in a session, Catalina has no choice but to authenticate you every time, because it has no way to know that the second request came from the same person or not. As a practical matter, when you are using BASIC and DIGEST authentication the browser keeps sending the "Authorization" header on each request with a matching "Realm", so the user does not see this happening -- but your Realm implementation does. Also, would there be any objection to my factoring out common functions from MemoryRealm, JDBCRealm and JAASRealm into an "AbstractRealm" helper class? There's a lot of cut-and-pasting to do when writing a Realm right now. I can post said class for review, since I am not a committer. There is already a RealmBase class which the current implementations subclass. Would it make sense to migrate common functionality there instead of creating another base class? --kd Craig
Re: realm always checked?
If you are in a session, the authenticated principal is actually cached (in a private variable inside the Session object). If you are not in a session, Catalina has no choice but to authenticate you every time, because it has no way to know that the second request came from the same person or not. I haven't put the session-handling code in my servlet yet, so there isn't one! Thanks, Craig. regards, kd
RE: 3.2 Branch Release Management
At least until someone else comes along and wants to do a better job at it :-). May be you'll need to find someone to do that job to help you be more on 4.0 ? Someone as proposed to do that some time ago. PS: What's the status of the RPM packaging for jakarta and xml projects ? At this point of time, I would suggest that we (committers) go ahead and apply patches as you receive and test them. When we've accumulated enough for another point release (3.2.2), we can go ahead and propose a temporary freeze on patches until the release is prepared, then open it up again. There have recently been a couple of security-related BugRat reports on 3.2. Any volunteers to look into these issues and prepare patches for them? Craig "Pour la plupart des hommes, se corriger consiste à changer de défauts." -- Voltaire -Original Message- From: Dan Milstein [mailto:[EMAIL PROTECTED]] Sent: Monday, December 25, 2000 11:44 PM To: [EMAIL PROTECTED] Subject: 3.2 Branch Release Management Does anyone have any opinions on a process for making commits to the 3.2 branch? Now that I've got my new fancy committer status, I'd like to check in some bug fixes there (to mod_jk / ajp13). However, before I do that, I wanted to check if there is anyone who is functioning as a Release Manager or anything like that. I'm only planning on checking in some tested bug fixes, just to be clear. -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: TC 4.0 vs. TC 3.x and division of labor
on 12/27/2000 10:24 AM, "Kyle F. Downey" [EMAIL PROTECTED] wrote:
I've been following of the TC4.0/TC3.2/TC3.3 threads for a while in
silence, and wanted to make an observation.
The Tomcat project really has two major types of customers: those who
want an open source servlet container for their production needs
("conservatives"), and those interested in the state-of-the-art
("tinkerers"). The project has made the decision--by supporting both 3.x
and 4.x in parallel--to try to serve both (a good decision, since I think
there are plenty of people in each user group).
The values of the conservatives are
* stability
* lack of bugs
* a seamless install
* performance
The values of the tinkerers are
* compliance with the latest standards ("100% buzzword compliant")
* advanced features
* elegance
Since I'm in your "tinkerer" group because I'm following the Catalina path
(like we agreed on), I will state that everything in your "conservative"
group is just as important to me in the "tinkerer" group.
Therefore, your distinct separation of the groups is illogical and moot.
These two groups have very little in common, except this: both will
tolerate change so long as it's in the direction of their values.
A
conservative will not argue with you about changing Tomcat 3.2 to 3.3 if
it's to make it faster, more stable, or less buggy. "More elegant" or
"more featureful" doesn't cut it, though, which is why I suspect there
will be little interest in Servlet 2.3 on top of 3.x (thus it's good for
it to be a "contrib" element, for the few who DO want such a combo).
I think so long as 3.3 is a move--as Costin says it is--toward a
better-factored, less-buggy version of 3.2, and all the changes taking
place are just moving around established, tested code, then it's a good
direction. I have consulting customers who may very well end their project
lifecycles still on servlet 2.1, old school or not!
So long as we keep in mind who's served by a change, and keep it
consistent with what that groups wants, I think we can safely move 3.x
through a fairly long arc.
The rest of this doesn't make any sense because I just stated that your
separation of the groups isn't defined correctly.
Try again.
There seems to be enough interest in each
viewpoint to support 3.x and 4.x at once without bogging down the project.
Actually, you are wrong here. The project is totally bogged down because
Craig (why didn't Costin step up to the plate to do this) is having to
spend time doing releases on Tomcat 3.x stuff instead of working on 4.x
stuff. If you have ever done a real live release of software, you will know
how hard it is and how much time it takes to make sure it is done right.
thanks,
-jon
Re: 3.2 Branch Release Management
GOMEZ Henri wrote: At least until someone else comes along and wants to do a better job at it :-). May be you'll need to find someone to do that job to help you be more on 4.0 ? Someone as proposed to do that some time ago. Yep -- 4.0 would progress faster (and I would get more sleep :-) if I knew that 3.2 was in good hands. PS: What's the status of the RPM packaging for jakarta and xml projects ? Last I heard, everyone was positive on the idea. I'll send you mail privately on how you can post files on the web server and update the website pages that point to them (since you're a committer). Craig
Re: TC 4.0 vs. TC 3.x and division of labor
Since I'm in your "tinkerer" group because I'm following the Catalina path (like we agreed on), I will state that everything in your "conservative" group is just as important to me in the "tinkerer" group. Therefore, your distinct separation of the groups is illogical and moot. Not necessarily. It's a matter of priority. Stability is more important than features to someone going into a production-ready environment, but both matter. Perhaps I wasn't clear about that. The rest of this doesn't make any sense because I just stated that your separation of the groups isn't defined correctly. I hope I cleared up what I meant. There seems to be enough interest in each viewpoint to support 3.x and 4.x at once without bogging down the project. Actually, you are wrong here. The project is totally bogged down because Craig (why didn't Costin step up to the plate to do this) is having to spend time doing releases on Tomcat 3.x stuff instead of working on 4.x stuff. If you have ever done a real live release of software, you will know how hard it is and how much time it takes to make sure it is done right. Of course. And, having done so, I also know that saying ALL things have equal priority (i.e. features + performance + stability + lack of bugs + latest-and-greatest standards) will never fly. Sooner or later, you make trade-offs. My point is that we have two groups interested (with representatives in the developers as well as the users) who have completely different ideas of those priorities. All you can do in this situation is a) abandon one group; or b) do the best you can, and divide labor to serve both, making sure you don't work to counter-purposes by having both projects try to be all things to all people. That's all I'm saying. This is slower, yes, I agree with you. But since we've heard vocal support for both 3.x and 4.x from that third community I didn't mention--the volunteers, who can work on one, the other, or nothing if they like--I don't think a) is going to happen. We might as well do (b) optimally instead of arguing about the costs of a compromise already made. regards, kd
Re: TC 4.0 vs. TC 3.x and division of labor
on 12/27/2000 11:40 AM, "Kyle F. Downey" [EMAIL PROTECTED] wrote: Since I'm in your "tinkerer" group because I'm following the Catalina path (like we agreed on), I will state that everything in your "conservative" group is just as important to me in the "tinkerer" group. Therefore, your distinct separation of the groups is illogical and moot. Not necessarily. It's a matter of priority. Stability is more important than features to someone going into a production-ready environment, but both matter. Perhaps I wasn't clear about that. Ok, look at the larger picture. Tomcat 3.1 was out there for a long time and it was crap (I think that everyone would agree on that one). Thus, we can ignore that one as a "release" with stability. Thus, the *only* reason why 3.2 got released was because Craig finally stood up and did a 3.2 release. Where was Mr. Costin during this time? He was working on 3.3 before 3.2 was ever released!!! In fact, people complained about that at the time as well. Thus, please explain to me how the "tinkerer" group isn't concerned about stability when the people doing the releases are from the "tinkerer" group!!! -rw-r--r-- 1 craigmcc jakarta 5283840 Nov 29 18:22 jakarta-tomcat-3.2.tar -rw-r--r-- 1 craigmcc jakarta 2781704 Nov 29 18:09 jakarta-tomcat-3.2.tar.gz -rw-r--r-- 1 craigmcc jakarta 3185249 Nov 29 18:14 jakarta-tomcat-3.2.zip Again, your point is moot. The rest of this doesn't make any sense because I just stated that your separation of the groups isn't defined correctly. I hope I cleared up what I meant. Nope. Of course. And, having done so, I also know that saying ALL things have equal priority (i.e. features + performance + stability + lack of bugs + latest-and-greatest standards) will never fly. Sooner or later, you make trade-offs. My point is that we have two groups interested (with representatives in the developers as well as the users) who have completely different ideas of those priorities. My point is that your groups are not delineated correctly if you sit down and look at the facts. I will also add that I was the release person for Apache JServ for about 90% of its life. Given that JServ probably still is the most stable servlet engine out there in Apache land, you can rest assured that I'm fully in favor of quality release stable software. I don't like being categorized like you categorized me. All you can do in this situation is a) abandon one group; or b) do the best you can, and divide labor to serve both, making sure you don't work to counter-purposes by having both projects try to be all things to all people. That's all I'm saying. No it isn't. Your original email was an attempt to classify people's interests "subject: ...division of labor" and I called you on it as being totally incorrect. If what you are saying above is now your new statement, then again, my point of my original "[MY_OPINION] Tomcat 3.x" thread is that having a split group is not conductive towards making quality software and I'm asking that this be resolved. The PMC meeting will resolve this for good. This is slower, yes, I agree with you. But since we've heard vocal support for both 3.x and 4.x from that third community I didn't mention--the volunteers, who can work on one, the other, or nothing if they like--I don't think a) is going to happen. We might as well do (b) optimally instead of arguing about the costs of a compromise already made. The *only* group that has a voice here is the people who have commit access. No one else has a voice. That is how the ASF works, it isn't a democracy. Please get used to it. http://jakarta.apache.org/site/decisions.html This will get finalized at the PMC meeting I'm sure, but as far as I see it, we had an agreement within the group that the future would be Catalina and the compromise hasn't been made yet and I'm calling attention to the fact that people are ignoring what we decided upon earlier. Therefore, anything else is simply a fork and should be done elsewhere until we come to a point where we can re-evaluate what the future is again. love, -jon
Re: An important question
on 12/27/2000 11:20 AM, "David Lavigne" [EMAIL PROTECTED] wrote: How can the future of Tomcat be 4.0 while it does not have connectors to the web servers that 3.x have? I believe that it will be the future as soon as these exist, otherwise there is no point in making Tomcat a separate product from Apache httpd when that is the only webserver Catalina supports. Maybe if we hadn't been focusing so hard on 3.x, then 4.0 would have had those features. *That* is the point. -jon
BugRat Report #591 was closed (apparently by: Marc Saegesser)
Report #591 was closed by Person #0 Synopsis: tomcat/doc/appdev/sample/build.bat error (logged in as: Marc Saegesser)
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util Base64.java
costin 00/12/27 11:52:57
Modified:.changes3.3
src/etc server.xml
src/share/org/apache/tomcat/request AccessInterceptor.java
JDBCRealm.java SimpleRealm.java
src/share/org/apache/tomcat/startup EmbededTomcat.java
src/share/org/apache/tomcat/task StopTomcat.java
src/share/org/apache/tomcat/util Base64.java
Added: src/share/org/apache/tomcat/request
CredentialsInterceptor.java
Removed: src/share/org/apache/tomcat/helper HostConfig.java
SecurityTools.java SessionUtil.java
src/share/org/apache/tomcat/startup HostConfig.java
Log:
Improvement in authentication code.
- use request notes to store user/password ( instead of creating Hashtable )
- transform SecurityTools in CredentialInterceptor. It's role is to
extract user/pass from FORM and BASIC and set them as notes.
- this makes the Realm independent of the authentication mechanism ( as
long as it's user/password - for other mechanisms a different realm is
needed. Both JDBC and File realms are specific to user/password schemes )
- moved the "authorize" code back to AccessInterceptor, realms no longer have
to worry about that.
- A "user-based" realm will use the 2 notes and set userRoles.
- removed more dead code.
Revision ChangesPath
1.4 +5 -0 jakarta-tomcat/changes3.3
Index: changes3.3
===
RCS file: /home/cvs/jakarta-tomcat/changes3.3,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- changes3.32000/12/07 18:40:53 1.3
+++ changes3.32000/12/27 19:52:49 1.4
@@ -1,5 +1,10 @@
CORE
+- improved authentication - a bit of performance and more flexibility
+ (CredentialInterceptor)
+
+- sealed the facade
+
- refactoring of MessageBytes
- refactoring of AJP1.3 ( Dan Milstein )
1.56 +6 -0 jakarta-tomcat/src/etc/server.xml
Index: server.xml
===
RCS file: /home/cvs/jakarta-tomcat/src/etc/server.xml,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- server.xml2000/12/27 17:15:00 1.55
+++ server.xml2000/12/27 19:52:50 1.56
@@ -187,6 +187,12 @@
className="org.apache.tomcat.request.AccessInterceptor"
debug="0" /
+!-- Implements BASIC and FORM autorization
+ --
+RequestInterceptor
+className="org.apache.tomcat.request.CredentialsInterceptor"
+debug="0" /
+
!-- Check permissions using the simple xml file. You can
plug more advanced authentication modules.
uncomment below to have a global tomcat Realm.
1.29 +35 -11
jakarta-tomcat/src/share/org/apache/tomcat/request/AccessInterceptor.java
Index: AccessInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/AccessInterceptor.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- AccessInterceptor.java2000/12/26 23:35:35 1.28
+++ AccessInterceptor.java2000/12/27 19:52:52 1.29
@@ -107,18 +107,13 @@
this.cm=cm;
// set-up a per/container note for maps
- try {
- secMapNote = cm.getNoteId( ContextManager.CONTAINER_NOTE,
-"map.security");
- // Used for inter-module communication - required role, tr
- reqRolesNote = cm.getNoteId( ContextManager.REQUEST_NOTE,
- "required.roles");
- reqTransportNote = cm.getNoteId( ContextManager.REQUEST_NOTE,
+ secMapNote = cm.getNoteId( ContextManager.CONTAINER_NOTE,
+"map.security");
+ // Used for inter-module communication - required role, tr
+ reqRolesNote = cm.getNoteId( ContextManager.REQUEST_NOTE,
+ "required.roles");
+ reqTransportNote = cm.getNoteId( ContextManager.REQUEST_NOTE,
"required.transport");
- } catch( TomcatException ex ) {
- log("engineInit(" + cm + ")", ex); // necessary?
- throw new RuntimeException( "Invalid state");
- }
}
public void contextInit( Context ctx)
@@ -284,6 +279,35 @@
}
}
return 0;
+}
+
+public int authorize( Request req, Response response, String roles[] )
+{
+if( roles==null || roles.length==0 ) {
+// request doesn't need authentication
+
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/utilBase64.java
on 12/27/2000 11:52 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED]
wrote:
+static int base64[]= {
shouldn't that be a final static int?
-jon
--
Honk if you love peace and quiet.
Re: An important question
Please don't start that again. --- Aaron Knauf Implementation Consultant Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com Jon Stevens [EMAIL PROTECTED] 28/12/2000 08:27 Please respond to tomcat-dev To:[EMAIL PROTECTED] cc: Subject:Re: An important question on 12/27/2000 11:20 AM, David Lavigne [EMAIL PROTECTED] wrote: How can the future of Tomcat be 4.0 while it does not have connectors to the web servers that 3.x have? I believe that it will be the future as soon as these exist, otherwise there is no point in making Tomcat a separate product from Apache httpd when that is the only webserver Catalina supports. Maybe if we hadn't been focusing so hard on 3.x, then 4.0 would have had those features. *That* is the point. -jon
Re: TC 4.0 vs. TC 3.x and division of labor
on 12/27/2000 11:09 AM, "Jon Stevens" [EMAIL PROTECTED] wrote: The *only* group that has a voice here is the people who have commit access. No one else has a voice. That is how the ASF works, it isn't a democracy. Please get used to it. I take back the part with a "voice". That is totally incorrect to say and essentially a typo. I should have stated "vote". s/voice/vote/ I apologize. -jon
Re: TC 4.0 vs. TC 3.x and division of labor
on 12/27/2000 11:58 AM, "Sam Ruby" [EMAIL PROTECTED] wrote: Likely waiting for the release manager at the time (me) to do his job. Craig indicated at the time that he was able to get relief from his employer to spend work time on putting out the 3.2 release - something we all very much appreciate. Point being that this is a volunteer organization and anyone, at any point (voted on of course) can stand up and do a release. In other words, Costin found time to work on 3.3, but didn't find time to either do a release or help Craig do a release. This will get finalized at the PMC meeting I'm sure, but as far as I see it, we had an agreement within the group that the future would be Catalina and the compromise hasn't been made yet and I'm calling attention to the fact that people are ignoring what we decided upon earlier. Can somebody point me to the mail archives where this decision was made? The existing jakarta-tomcat module is proposed to continue as it currently exists (except for being renamed), for use in supporting the Tomcat 3.x code for as long as this is appropriate. Nope. I think that is why the PMC meeting is being called. To clear this up once and for all. There was some good discussion under the subject: "Tomcat, Catalina, and Java2", but I didn't save it all and I didn't see a final decision there. Maybe I'm even incorrect with my statement however, the path that I "felt" we were going down was having Catalina be Tomcat 4.x and I haven't seen anyone really object to that yet (especially given that that is the CVS module name for Catalina). The issue has been to this point what will be Tomcat 3.3 (if anything). thanks, -jon
Tomcat 4 SecurityManager code
I had looked at the code a while ago, and at that time the code to implement the Java SeucrityManager had been ported from Tomcat 3.2. When I looked at the code today, it is entirely different and unfinished. I was wondering who had been working on this and if they were planning on finishing it anytime in the near future. If not, I can spend some time finishing it up (most likely rewriting or reimplementing the Tomcat 3.x SecurityManager code). Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/collections SimpleHashtable.java
costin 00/12/27 13:23:18
Modified:src/share/org/apache/tomcat/util/collections
SimpleHashtable.java
Log:
Added the missing remove() method.
Revision ChangesPath
1.2 +20 -3
jakarta-tomcat/src/share/org/apache/tomcat/util/collections/SimpleHashtable.java
Index: SimpleHashtable.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/collections/SimpleHashtable.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SimpleHashtable.java 2000/11/30 17:34:17 1.1
+++ SimpleHashtable.java 2000/12/27 21:23:17 1.2
@@ -97,7 +97,7 @@
* it makes a significant difference when normalizing attributes,
* which is done for each start-element construct.
*
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public final class SimpleHashtable implements Enumeration
{
@@ -308,8 +308,25 @@
return null;
}
-public void remove(Object o) {
-
+public Object remove(Object key) {
+ Entry tab[] = table;
+ Entry prev=null;
+ int hash = key.hashCode();
+ int index = (hash 0x7FFF) % tab.length;
+ for (Entry e = tab[index] ; e != null ; prev=e, e = e.next) {
+ if ((e.hash == hash) e.key.equals(key)) {
+ if( prev!=null ) {
+ prev.next=e.next;
+ } else {
+ tab[index]=e.next;
+ }
+ }
+ count--;
+ Object res=e.value;
+ e.value=null;
+ return res;
+ }
+ return null;
}
/**
Re: TC 4.0 vs. TC 3.x and division of labor
on 12/27/2000 12:59 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Nacho and Larry and Henri did most of the hard work in maintaining 3.2, and it is a _team_ effort. Sam acted as a release manager - doing build after build, as he was supposed to do. Tomcat 3.2 is not _my_ product, but _our_ product, and I think _we_ did a good job overall. I agree. I'm not disputing that. I wrote _a_lot__ of the code that went into 3.2, and I did more work than you can imagine, Jon. I did that even if I had a job that is not tomcat, but xml-xalan. In fact, you did some of that work during your day time job. :-) After 3.2 was frozen I had far more work than I could handle with xalan and jaxp ( thanks to Scott for helping me so much ), and the little free time I got was put into finishing what I started - the refactoring of tomcat3, making it _elegant_ and _fast_ .. Actually, you did that before 3.2 was frozen, didn't you? I remember an email thread asking why work was starting on 3.3 when 3.2 wasn't even done yet. In any case - this is not about me, but about tomcat. I do my best to improve tomcat, if that's not enough for you - I'm sorry. Tomcat 3.x or 4.x? -jon
cvs commit: jakarta-tomcat/src/admin/contextAdmin contextAdd.jsp contextRemove.jsp moduleList.jsp contextAdmin.html contextAdmin.jsp contextList.jsp ctxDetail.jsp
costin 00/12/27 13:41:33
Modified:src/admin index.html
src/admin/WEB-INF admin.tld
src/admin/WEB-INF/classes/tadm TomcatAdmin.java
src/admin/contextAdmin contextAdmin.html contextAdmin.jsp
contextList.jsp ctxDetail.jsp
Added: src/admin/contextAdmin contextAdd.jsp contextRemove.jsp
moduleList.jsp
Removed: src/admin/WEB-INF/classes ContextAdmin.java
Log:
- update /admin app
- moved the code from ContextAdmin ( used as bean in contextAdmin.jsp )
to TomcatAdmin ( tag library )
- added small jsp files to add/remove ( using tag libraries instead of
bean)
- tested add/remove/add back - the code still needs work ( support for
virtual hosts, support for adding/removing modules at runtime,
support for restarting, etc), but at least we have a start.
Volunteers welcome :-)
Revision ChangesPath
1.2 +2 -0 jakarta-tomcat/src/admin/index.html
Index: index.html
===
RCS file: /home/cvs/jakarta-tomcat/src/admin/index.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.html2000/02/18 18:33:02 1.1
+++ index.html2000/12/27 21:41:23 1.2
@@ -27,6 +27,8 @@
br
ul
+ lia href="./contextAdmin/contextList.jsp"Context list/a
+ lia href="./contextAdmin/moduleList.jsp"Modules/a
lia href="./contextAdmin/contextAdmin.html"Context Admin/a
lia href="/examples/jsp/snp/snoop.jsp"Snoop/a
/ul
1.2 +17 -0 jakarta-tomcat/src/admin/WEB-INF/admin.tld
Index: admin.tld
===
RCS file: /home/cvs/jakarta-tomcat/src/admin/WEB-INF/admin.tld,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- admin.tld 2000/07/25 20:13:26 1.1
+++ admin.tld 2000/12/27 21:41:26 1.2
@@ -23,11 +23,28 @@
Admin
/info
attribute
+ nameaction/name
+ requiredfalse/required
+/attribute
+attribute
namectxPathParam/name
requiredfalse/required
/attribute
attribute
+ namedocBaseParam/name
+ requiredfalse/required
+/attribute
+attribute
+ namedocBase/name
+ requiredfalse/required
+/attribute
+attribute
namectxPath/name
+ requiredfalse/required
+ rtexprvaluetrue/rtexprvalue
+/attribute
+attribute
+ namectxHost/name
requiredfalse/required
rtexprvaluetrue/rtexprvalue
/attribute
1.5 +60 -8 jakarta-tomcat/src/admin/WEB-INF/classes/tadm/TomcatAdmin.java
Index: TomcatAdmin.java
===
RCS file: /home/cvs/jakarta-tomcat/src/admin/WEB-INF/classes/tadm/TomcatAdmin.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TomcatAdmin.java 2000/10/02 02:04:36 1.4
+++ TomcatAdmin.java 2000/12/27 21:41:29 1.5
@@ -7,9 +7,7 @@
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;
-import org.apache.tomcat.core.Request;
-import org.apache.tomcat.core.Context;
-import org.apache.tomcat.core.ContextManager;
+import org.apache.tomcat.core.*;
import org.apache.tomcat.helper.RequestUtil;
/**
@@ -19,8 +17,12 @@
*/
public class TomcatAdmin extends TagSupport {
private ContextManager cm;
-String ctxPathParam;
String ctxPath;
+String docBase;
+String ctxPathParam;
+String docBaseParam;
+String action;
+String host;
PageContext pageContext;
public TomcatAdmin() {}
@@ -31,19 +33,30 @@
getRequest();
init(req);
pageContext.setAttribute("cm", cm);
- if( ctxPathParam != null ) {
+ Context ctx=null;
+ if( ctxPath==null ctxPathParam!=null ) {
ctxPath=req.getParameter( ctxPathParam );
}
+ if( docBase==null docBaseParam!=null) {
+ docBase=req.getParameter( docBaseParam );
+ }
+
if( ctxPath != null ) {
+ System.out.println("Finding " + ctxPath );
Enumeration en=cm.getContexts();
while( en.hasMoreElements() ) {
- Context ctx=(Context)en.nextElement();
+ ctx=(Context)en.nextElement();
+ // XXX virtual host
if( ctxPath.equals( ctx.getPath())) {
pageContext.setAttribute("ctx", ctx);
break;
}
}
}
+ if("removeContext".equals( action ) )
+ removeContext( cm , ctx);
+ if("addContext".equals( action ) )
+
edit bug #56 by person #0 (logged in as: Marc Saegesser)
Work around description modified: Description changed from: To: Use W3C Extended Log File Format. This log file format includes the request URI even for filtered requests.
Re: TC 4.0 vs. TC 3.x and division of labor
Jon, I defend your right to an opinion. Now will you please voluntarily quit this? I'm asking you, amigo, please don't put out fire with gasoline. It's not condusive to anything. Have some fraternity, brutha! \n On Wed, 27 Dec 2000, Jon Stevens wrote: on 12/27/2000 12:59 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Nacho and Larry and Henri did most of the hard work in maintaining 3.2, and it is a _team_ effort. Sam acted as a release manager - doing build after build, as he was supposed to do. Tomcat 3.2 is not _my_ product, but _our_ product, and I think _we_ did a good job overall. I agree. I'm not disputing that. I wrote _a_lot__ of the code that went into 3.2, and I did more work than you can imagine, Jon. I did that even if I had a job that is not tomcat, but xml-xalan. In fact, you did some of that work during your day time job. :-) After 3.2 was frozen I had far more work than I could handle with xalan and jaxp ( thanks to Scott for helping me so much ), and the little free time I got was put into finishing what I started - the refactoring of tomcat3, making it _elegant_ and _fast_ .. Actually, you did that before 3.2 was frozen, didn't you? I remember an email thread asking why work was starting on 3.3 when 3.2 wasn't even done yet. In any case - this is not about me, but about tomcat. I do my best to improve tomcat, if that's not enough for you - I'm sorry. Tomcat 3.x or 4.x? -jon
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util Base64.java
Hola Costin:
Comments intermixed below.
-public int authorize( Request req, Response response,
String roles[] )
-{
-if( roles==null ) {
-// request doesn't need authentication
-return 0;
-}
-
-Context ctx=req.getContext();
-
-String userRoles[]=null;
-
- String user=req.getRemoteUser();
-
- if( user==null )
-return 401; //HttpServletResponse.SC_UNAUTHORIZED
-
-if( this.equals(req.getNote(reqRealmSignNote)) ){
-return 0;
-}
IMHO we cannot lost this last check, as is the way multiple Overlapping
Realms can be used , we need to distinguish between the realm that
actually authenticate a user, to let it do the authorization..., this
was the idea behind the realmSignNote, how can we that now?.
+// XXX XXX XXX Nacho, I think Digest should be part of
the Credential
+// module, so it's used by all Realms.
+
but if we do things that way, how can i configure a JDBCRealm to use
digested passwords and others dont?? we will need to use a private
CredentialsInterceptor for the context that needs Digested passwords ?
Saludos ,
Ignacio J. Ortega
Re: TC 4.0 vs. TC 3.x and division of labor
I wrote _a_lot__ of the code that went into 3.2, and I did more work than you can imagine, Jon. I did that even if I had a job that is not tomcat, but xml-xalan. In fact, you did some of that work during your day time job. :-) And thanks to my managers for not firing me, I'm lucky to work where I work. So far I reached all the deadlines I had, and I'm quite happy with the results. After 3.2 was frozen I had far more work than I could handle with xalan and jaxp ( thanks to Scott for helping me so much ), and the little free time I got was put into finishing what I started - the refactoring of tomcat3, making it _elegant_ and _fast_ .. Actually, you did that before 3.2 was frozen, didn't you? I remember an email thread asking why work was starting on 3.3 when 3.2 wasn't even done yet. Your honor, I did work on 3.3 since 3.0 - that's when refactoring was started. Most of what happens in 3.3 was thought during 3.2 development - and I also implemented big chunks at that time. I haven't checked them in because I wanted to spend more time on some issues ( like the OutputBuffer, MessageBytes ) and do more testing. But in any case, the commits were made _after_ 32 branch was tagged ( otherwise the change would have gone into 3.2 ). Remember that the so-called 3.3 is the main branch - and "freeze" means tagging the workspace for a release. It's how CVS works. In any case - this is not about me, but about tomcat. I do my best to improve tomcat, if that's not enough for you - I'm sorry. Tomcat 3.x or 4.x? My belief is that 3.x is better, more elegant, more stable, etc - and that's where I'll spend most of my time. I know there are 2 different codebases sharing the same name - and there is a lot of good code in 4.0 - and I plan to merge whatever is good in 4.0 into tomcat3.3 modules ( again, in a separate tree ) - so 3.3 users will get the best of both. Costin
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util Base64.java
Forget the first comment ( i'll delete realmSignNote soon :), i think
the second comment remains... intelligent? :-), i dont know.
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: Nacho [mailto:[EMAIL PROTECTED]]
Enviado el: miércoles 27 de diciembre de 2000 23:23
Para: '[EMAIL PROTECTED]'
Asunto: RE: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/util
Base64.java
Hola Costin:
Comments intermixed below.
-public int authorize( Request req, Response response,
String roles[] )
-{
-if( roles==null ) {
-// request doesn't need authentication
-return 0;
-}
-
-Context ctx=req.getContext();
-
-String userRoles[]=null;
-
- String user=req.getRemoteUser();
-
- if( user==null )
-return 401; //HttpServletResponse.SC_UNAUTHORIZED
-
-if( this.equals(req.getNote(reqRealmSignNote)) ){
-return 0;
-}
IMHO we cannot lost this last check, as is the way multiple
Overlapping
Realms can be used , we need to distinguish between the realm that
actually authenticate a user, to let it do the authorization..., this
was the idea behind the realmSignNote, how can we that now?.
+// XXX XXX XXX Nacho, I think Digest should be part of
the Credential
+// module, so it's used by all Realms.
+
but if we do things that way, how can i configure a JDBCRealm to use
digested passwords and others dont?? we will need to use a private
CredentialsInterceptor for the context that needs Digested
passwords ?
Saludos ,
Ignacio J. Ortega
Re: Tomcat 4 SecurityManager code
Glenn Nielsen wrote: I had looked at the code a while ago, and at that time the code to implement the Java SeucrityManager had been ported from Tomcat 3.2. When I looked at the code today, it is entirely different and unfinished. I was wondering who had been working on this and if they were planning on finishing it anytime in the near future. If not, I can spend some time finishing it up (most likely rewriting or reimplementing the Tomcat 3.x SecurityManager code). I had started working on this, but quickly came to the conclusion that I don't know enough about how protection domains work -- and the arcane games we had to play in Tomcat 3.x to maintain JDK 1.1 compatibility made that code indecipherable to me. I would really really appreciate your help on getting this stuff to work in Tomcat 4.0. Regards, Glenn Craig
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util Base64.java
Hi Nacho,
Sorry about this - I'll fix it back if it broke something. I was not sure
about the way Digest worked, and I wanted to find a way to use it in all
realms.
-public int authorize( Request req, Response response,
String roles[] )
-if( this.equals(req.getNote(reqRealmSignNote)) ){
-return 0;
-}
IMHO we cannot lost this last check, as is the way multiple Overlapping
Realms can be used , we need to distinguish between the realm that
actually authenticate a user, to let it do the authorization..., this
was the idea behind the realmSignNote, how can we that now?.
I was thinking that the realm that does authenticate will set the user
roles ( i.e. check user/password, if correct extract the roles for the
user and set them in the request ).
When AccessInterceptor does the authorize(), it doesn't matter which realm
found the roles - all it matters is that a realm ( that is
configured in the server of context setup ) found the request to be
authenticated and the user to have certain roles.
We can certainly add back the check and move back authorize() to Realms,
but I would be happier if we find a way to avoid repeating it in all
realms.
+// XXX XXX XXX Nacho, I think Digest should be part of
the Credential
+// module, so it's used by all Realms.
+
but if we do things that way, how can i configure a JDBCRealm to use
digested passwords and others dont?? we will need to use a private
CredentialsInterceptor for the context that needs Digested passwords ?
To be honest, I don't know too much about Digest authentication - you
spent more time on this issue anyway.
My understanding is that the browser will send a "Authentication: Digest",
and CredentialInterceptor can save this response in the request, as
"password" ( or pasword-signed-secret, in this case ). This way the code
can be shared by all Realms.
I'm not very sure about this subject - and if you feel we should roll back
the changes I can do it.
In any case, the configuration for digest authentication should be in
web.xml or in the context configuration, not in the realm ( IMHO )
Costin
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util B ase64.java
To be honest, I don't know too much about Digest authentication - you spent more time on this issue anyway. You are confused with this code, this enables the ability of use Digested passwords in the JDBCRealm nothing to do with DIGEST auth, it's only to read digested passwords from the RDBMS.. :-) i'll attack soon with DIGEST auth but not now.. Aaaa. In this case - there is no problem, authenticate() will un-digest the data from RDBMS, etc. Of course, it would be nice to have the code factored out - maybe we can use digest for the MemoryRealm ( or other future realms ) too. ( another nice feature would be to support "unix"-like digests and mySQL-like password digests ). Again - as an util if possible :-) Costin
RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util B ase64.java
Hola Costin: Of course, it would be nice to have the code factored out - maybe we can use digest for the MemoryRealm ( or other future realms ) too. Agree. ( another nice feature would be to support "unix"-like digests and mySQL-like password digests ). Again - as an util if possible :-) Please expand on this a little, what is it a "unix"-like digest? , the one that goes in /etc/passwd? and mySQL-like password digest ?, i dont know mySql, i'm used to Oracle.., and i use the same code inside 8.1.6 without complaints :-). Costin Saludos , Ignacio J. Ortega
cvs commit: jakarta-tomcat-4.0/catalina/docs tomcat-4.0.jpg
jon 00/12/27 16:21:24 Added: catalina/docs tomcat-4.0.jpg Log: add image done by pier a long time ago as it is pretty nice and we shouldn't loose it Revision ChangesPath 1.1 jakarta-tomcat-4.0/catalina/docs/tomcat-4.0.jpg Binary file
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request JDBCRealm.java SimpleRealm.java
nacho 00/12/27 16:46:15
Modified:src/share/org/apache/tomcat/request JDBCRealm.java
SimpleRealm.java
Log:
*realmSigNote is not needed now.
* Now is needed to have both a connectionName
and a connectionPassword to use the 3 params getConnection
method
Thanks to David Weinrich [[EMAIL PROTECTED]]
for catch this
Revision ChangesPath
1.27 +9 -16
jakarta-tomcat/src/share/org/apache/tomcat/request/JDBCRealm.java
Index: JDBCRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/JDBCRealm.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- JDBCRealm.java2000/12/27 19:52:52 1.26
+++ JDBCRealm.java2000/12/28 00:46:14 1.27
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/JDBCRealm.java,v 1.26
2000/12/27 19:52:52 costin Exp $
- * $Revision: 1.26 $
- * $Date: 2000/12/27 19:52:52 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/JDBCRealm.java,v 1.27
2000/12/28 00:46:14 nacho Exp $
+ * $Revision: 1.27 $
+ * $Date: 2000/12/28 00:46:14 $
*
* The Apache Software License, Version 1.1
*
@@ -65,10 +65,7 @@
import org.apache.tomcat.core.*;
import org.apache.tomcat.helper.*;
import org.apache.tomcat.util.*;
-import org.apache.tomcat.util.xml.*;
import java.security.*;
-import java.beans.PropertyChangeListener;
-import java.beans.PropertyChangeSupport;
import java.security.Principal;
import java.io.File;
import java.util.Enumeration;
@@ -101,7 +98,6 @@
ContextManager cm;
int reqRolesNote;
-int reqRealmSignNote;
int userNote;
int passwordNote;
// - Instance Variables
@@ -387,7 +383,7 @@
if( (dbConnection == null) || dbConnection.isClosed() ) {
Class.forName(driverName);
log(sm.getString("jdbcRealm.checkConnectionDBClosed"));
-if ((connectionName == null || connectionName.equals(""))
+if ((connectionName == null || connectionName.equals("")) ||
(connectionPassword == null ||
connectionPassword.equals(""))) {
dbConnection = DriverManager.getConnection(connectionURL);
} else {
@@ -406,7 +402,7 @@
return false;
}
catch( ClassNotFoundException ex ) {
-throw new RuntimeException("JDBCRealm.contextInit: " + ex);
+throw new RuntimeException("JDBCRealm.checkConnection: " + ex);
}
}
@@ -487,6 +483,7 @@
throws org.apache.tomcat.core.TomcatException {
// Validate and update our current component state
if (started) {
+started=false;
try {
if( dbConnection != null !dbConnection.isClosed())
dbConnection.close();
@@ -501,7 +498,7 @@
String user=(String)req.getNote( userNote );
String password=(String)req.getNote( passwordNote );
if( user==null) return 0;
-
+
if( checkPassword( user, password ) ) {
if( debug 0 ) log( "Auth ok, user=" + user );
Context ctx = req.getContext();
@@ -509,7 +506,7 @@
req.setAuthType(ctx.getAuthMethod());
if( user!=null) {
req.setRemoteUser( user );
- req.setNote(reqRealmSignNote,this);
+// req.setNote(reqRealmSignNote,this);
String userRoles[] = getUserRoles( user );
req.setUserRoles( userRoles );
}
@@ -517,9 +514,7 @@
return 0;
}
-// XXX XXX XXX Nacho, I think Digest should be part of the Credential
-// module, so it's used by all Realms.
-
+
/**
* Digest password using the algorithm especificied and
* convert the result to a corresponding hex string.
@@ -577,8 +572,6 @@
// XXX make the name a "global" static - after everything is stable!
reqRolesNote = cm.getNoteId( ContextManager.REQUEST_NOTE
, "required.roles");
-reqRealmSignNote = cm.getNoteId( ContextManager.REQUEST_NOTE
-, "realm.sign");
userNote=cm.getNoteId( ContextManager.REQUEST_NOTE,
"credentials.user");
passwordNote=cm.getNoteId( ContextManager.REQUEST_NOTE,
1.17 +1 -5
jakarta-tomcat/src/share/org/apache/tomcat/request/SimpleRealm.java
Index: SimpleRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/request/SimpleRealm.java,v
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup SimpleTomcat.java EmbededTomcat.java
costin 00/12/27 17:13:30
Modified:src/share/org/apache/tomcat/startup EmbededTomcat.java
Added: src/share/org/apache/tomcat/startup SimpleTomcat.java
Log:
Another step in refactoring EmbededTomcat.
Revision ChangesPath
1.37 +100 -141
jakarta-tomcat/src/share/org/apache/tomcat/startup/EmbededTomcat.java
Index: EmbededTomcat.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/EmbededTomcat.java,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- EmbededTomcat.java2000/12/27 19:52:54 1.36
+++ EmbededTomcat.java2000/12/28 01:13:29 1.37
@@ -12,12 +12,14 @@
import java.security.*;
import java.util.*;
-// XXX XXX This started as a hack to integrate with J2EE,
-// need a major rewrite
-
/**
- * Use this class to embed tomcat in your application.
+ *
+ * Wrapper around ContextManager. Use this class to embed tomcat in your
+ * application if you want to use "API"-based configuration ( instead
+ * or in addition to server.xml ).
+ *
* The order is important:
+ *
* 1. set properties like workDir and debug
* 2. add all interceptors including your application-specific
* 3. add the endpoints
@@ -37,19 +39,18 @@
* @author [EMAIL PROTECTED]
*/
public class EmbededTomcat {
-ContextManager contextM = new ContextManager();
-Object application;
+// the "real" server
+protected ContextManager contextM = new ContextManager();
-// null == not set up
-Vector requestInt=null;
-Vector connectors=new Vector();
+// your application
+protected Object application;
-String workDir;
+// null == not set up
+protected Vector requestInt=null;
+protected Vector connectors=new Vector();
-Log loghelper = new Log("tc_log", this);
-
// configurable properties
-int debug=0;
+protected int debug=0;
public EmbededTomcat() {
}
@@ -64,24 +65,24 @@
*/
public void setDebug( int debug ) {
this.debug=debug;
+ contextM.setDebug( debug );
}
+
+// Application Modules
+
/** This is an adapter object that provides callbacks into the
* application.
- * For tomcat, it will be a BaseInterceptor.
- * See the top level documentation
*/
-public void addApplicationAdapter( Object adapter )
+public void addApplicationAdapter( BaseInterceptor adapter )
throws TomcatException
{
if(requestInt==null) initDefaultInterceptors();
-
- // In our case the adapter must be BaseInterceptor.
- if ( adapter instanceof BaseInterceptor ) {
- addInterceptor( (BaseInterceptor)adapter);
- }
+ addInterceptor(adapter);
}
+/** Keep a reference to the application in which we are embeded
+ */
public void setApplication( Object app ) {
application=app;
}
@@ -90,16 +91,11 @@
*/
public Object getApplication() {
return application;
-}
-
-public void setWorkDir( String dir ) {
- workDir=dir;
}
-
-// Endpoints
+
+// Helpers for http connectors
/** Add a HTTP listener.
- * You must add all the endpoints before calling start().
*/
public void addEndpoint( int port, InetAddress addr , String hostname)
throws TomcatException
@@ -108,8 +104,22 @@
" " + hostname );
Http10Interceptor sc=new Http10Interceptor();
- sc.setServer( contextM );
- sc.setDebug( debug );
+ sc.setPort( port ) ;
+ if( addr != null ) sc.setAddress( addr );
+ if( hostname != null ) sc.setHostName( hostname );
+
+ contextM.addInterceptor( sc );
+}
+
+/** Add AJP12 listener.
+ */
+public void addAjpEndpoint( int port, InetAddress addr , String hostname)
+ throws TomcatException
+{
+ if(debug0) log( "addAjp12Connector " + port + " " + addr +
+ " " + hostname );
+
+ Ajp12Interceptor sc=new Ajp12Interceptor();
sc.setPort( port ) ;
if( addr != null ) sc.setAddress( addr );
if( hostname != null ) sc.setHostName( hostname );
@@ -127,7 +137,6 @@
hostname );
Http10Interceptor sc=new Http10Interceptor();
- sc.setServer( contextM );
sc.setPort( port ) ;
if( addr != null ) sc.setAddress( addr );
if( hostname != null ) sc.setHostName( hostname );
@@ -142,12 +151,13 @@
boolean initialized=false;
-/**
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/request AccessInterceptor.java
costin 00/12/27 17:15:39
Modified:src/facade22/org/apache/tomcat/facade ServletHandler.java
src/j2ee/org/apache/tomcat/j2ee J2EEInterceptor.java
TomcatJ2EEAdapter.java
src/share/org/apache/tomcat/core BaseInterceptor.java
ContextManager.java
src/share/org/apache/tomcat/request AccessInterceptor.java
Log:
Use Apache conventions for access interceptors ( need to do the same
for all hooks ). This is important because the whole 3.x design is based
on the same module structure, and it is confusing to use different return
codes. It'll also be important for module developers - and possible
use of "native" apache modules in tomcat authentication ( based on ajp13
evolution and support for more call types )
Revision ChangesPath
1.11 +1 -1
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletHandler.java
Index: ServletHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletHandler.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ServletHandler.java 2000/12/27 17:15:03 1.10
+++ ServletHandler.java 2000/12/28 01:15:37 1.11
@@ -85,7 +85,7 @@
* @author Harish Prabandham
* @author Costin Manolache
*/
-final class ServletHandler extends Handler {
+public final class ServletHandler extends Handler {
/**
* If init() fails or preInit() detects the handler is still
1.7 +16 -12
jakarta-tomcat/src/j2ee/org/apache/tomcat/j2ee/J2EEInterceptor.java
Index: J2EEInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/j2ee/org/apache/tomcat/j2ee/J2EEInterceptor.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- J2EEInterceptor.java 2000/12/27 07:21:12 1.6
+++ J2EEInterceptor.java 2000/12/28 01:15:37 1.7
@@ -50,6 +50,8 @@
private static final String HTTP_ERROR_LOG = "web.error.log";
private static final int BUFFER_SIZE = 1024;
+int userNote;
+int passwordNote;
// auth
private static int MAX_COUNT = 5;
private static int SLEEP_TIME = 5000; // milliseconds
@@ -65,6 +67,11 @@
public void engineInit( ContextManager cm ) throws TomcatException {
super.engineInit(cm);
+ userNote=cm.getNoteId( ContextManager.REQUEST_NOTE,
+"credentials.user");
+ passwordNote=cm.getNoteId( ContextManager.REQUEST_NOTE,
+"credentials.password");
+
debug=10;
}
@@ -72,7 +79,7 @@
throws TomcatException
{
}
-
+
public int preService(Request request, Response response) {
Context ctx = request.getContext();
Handler sw=request.getHandler();
@@ -180,13 +187,9 @@
public int authenticate( Request req, Response res ) {
Context ctx=req.getContext();
- // Extract the credentials
- Hashtable cred=new Hashtable();
- SecurityTools.credentials( req, cred );
-
// This realm will use only username and password callbacks
- String user=(String)cred.get("username");
- String password=(String)cred.get("password");
+ String user=(String)req.getNote( userNote );
+ String password=(String)req.getNote( passwordNote );;
if( debug0 ) log( "Try to auth " + user + " " + password);
if( user==null || password == null ) {
@@ -232,8 +235,8 @@
public int authorize( Request req, Response response, String roles[] )
{
- if( roles==null ) {
- return 0;
+ if( roles==null || roles.length==0 ) {
+ return OK;
}
Context ctx=req.getContext();
@@ -245,11 +248,12 @@
appName=wbd.getApplication().getName();
if( debug0) log("appname=" + appName);
+ // call back the authenticate hooks
String user=req.getRemoteUser();
if( user==null ) {
// Need auth, but have no user/pass
if( debug0) log("no username");
- return HttpServletResponse.SC_UNAUTHORIZED;
+ return DECLINED;
}
String userRoles[]=null;
@@ -267,7 +271,7 @@
if(isUserInRole(appName, mappedRole) ) {
if( debug0 ) log("Role match " +
roles[i] + " " + mappedRole);
- return 0;
+ return OK;
}
if( debug0 ) log("Role match failed " +
roles[i] + " " + mappedRole);
@@ -275,7 +279,7 @@
if( debug0 ) log("UnAuthorized " +
role + " " +
Unsubscribe tomcat-dev
Unsubscribe tomcat-dev
Re: TC 4.0 vs. TC 3.x and division of labor
on 12/28/2000 01:02 AM, "Jon Stevens" [EMAIL PROTECTED]
wrote:
on 12/27/2000 3:42 PM, "Craig R. McClanahan" [EMAIL PROTECTED]
wrote:
http://w6.metronet.com/~wjm/tomcat/2000/Aug/index.html#00195
I remember this now as I was late on my response! :-)
Where is Costin's response? He is the *only* person who didn't respond.
H...
I also see _tons_ of +1's and zero -1's. Therefore, one can conclude that
the direction is clear. We just need to execute on it.
p.s. I also find this paragraph from Nacho very interesting...
http://w6.metronet.com/~wjm/tomcat/2000/Aug/msg00253.html
"i will prefer that when tomcat-4.0 come to life as Tomcat 4.0 change the
old Tomcat to "jakarta-tomcat-3.0" and then change "jakarta-tomcat-4.0"
to main as "jakarta-tomcat" this no much complicated for us and is far
better the average user, there are only one "MAIN" line in development."
So, what I'm proposing and complaining about is *exactly* what Nacho stated
that he wanted to see. H..
Yes and maybe he now sees it otherwise!
Like you did a few hours after you wrote this in your "Fuck It" mail:
"I give up. All of my previous -1 votes are now +1. Have fun."
I would not call what your doing now "giving up".
Could you please please please "give up" now.
Why don't you concentrate on commiting stuff for 4.0 instead of picking on Costin and
3.3.
In the last 80 days you have done 6 commits but send 153 other mails. Even though many
of them where ok, many of them where negative and nonconstructive, like "I keep
looking at this code and realizing how bad it is. :-(" and so on. I don't see you are
doing much good for the Jakarta projekt rigth now.
Please change track: Make code not war :-).
Casper Gjerris
unsubscribe jakarta-tomcat-cvs
unsubscribe jakarta-tomcat-cvs
Re: [BUG? PATCH] for Kaffe VM
I found problem that tomcat 3.2-b8 doesn't work on Kaffe VM.
(probably 3.2 final is same)
Error occurs at read() method in java.io.BufferedInputStream.
# Maybe it's Kaffe VM's problem.(which has problem?)
Kaffe developer resolved this problem in Kaffe VM.
We won't need following patch for next Kaffe release.
*** RecycleBufferedInputStream.java.org Sat Dec 9 02:35:35 2000
--- RecycleBufferedInputStream.java Sat Dec 9 02:35:57 2000
***
*** 73,83
--- 73,85
public void setInputStream( InputStream is ) {
this.count=0;
this.in=is;
+ this.pos=0;
}
public void recycle() {
this.in=null;
this.count=0;
+ this.pos=0;
}
---
Takashi Okamoto
Re: Tomcat 4 SecurityManager code
"Craig R. McClanahan" wrote: Glenn Nielsen wrote: I had looked at the code a while ago, and at that time the code to implement the Java SeucrityManager had been ported from Tomcat 3.2. When I looked at the code today, it is entirely different and unfinished. I was wondering who had been working on this and if they were planning on finishing it anytime in the near future. If not, I can spend some time finishing it up (most likely rewriting or reimplementing the Tomcat 3.x SecurityManager code). I had started working on this, but quickly came to the conclusion that I don't know enough about how protection domains work -- and the arcane games we had to play in Tomcat 3.x to maintain JDK 1.1 compatibility made that code indecipherable to me. I would really really appreciate your help on getting this stuff to work in Tomcat 4.0. Ok, I'll get started. I haven't looked at the Tomcat 4 code base much yet. Give me a chance to digest the ContextManager, ClassLoaders, and Jasper architecture. Then I'll put together a design doc so others can comment on how the SecurityManager is hooked in. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
QueryString with multibyte characters
Hi, Tomcat 3.2.1, as standalone container, do handle well QueryString with multibyte characters. But Tomcat 3.2.1, as out-f-process container, does not. I confirm that both of mod_jserv and mod_jk have some bug in handling uri and querystring. Kim
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/hooks - New directory
costin 00/12/27 22:04:09 jakarta-tomcat/src/share/org/apache/tomcat/util/hooks - New directory
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/hooks Hooks.java
costin 00/12/27 22:15:21
Added: src/share/org/apache/tomcat/util/hooks Hooks.java
Log:
First attempt to refactor hooks. Moving them in a util package is not a
bad idea ( and it's inspired by the new organization in 2.0 - I was
initially surprized to find ap_hook.h in apr-utils, but it's quite a generic
concept ).
The only disadvantage of using "generic" hooks is that a cast is
needed ( to BaseInterceptor ), but it gives a lot more flexibility.
I think there is a simple workaround for that.
Revision ChangesPath
1.1 jakarta-tomcat/src/share/org/apache/tomcat/util/hooks/Hooks.java
Index: Hooks.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 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.tomcat.util.hooks;
import org.apache.tomcat.util.*;
import java.io.*;
import java.net.*;
import java.util.*;
import java.lang.reflect.*;
/** Hooks support. Hooks implement a chain-of-command pattern, and
* are commonly used in most web servers as a mechanism of extensibility.
*
* This class doesn't deal with hook invocation - the program is expected
* to use interfaces or base classes with the hooks beeing methods that
* are invoked. Reflection-based invocation is very expensive and shouldn't
* be used.
*
* The Hooks class will provide support for registering and maintaining
* a list of modules implementing each hook.
*
* The module can be added automatically to the right lists by using
* introspection ( if the module implements a certain method, it'll
* be added to the chain for the hook with the same name ). It is also
* possible for a module to explicitely register hooks.
*
* This class is modeled after Apache2.0 hooks - most web servers are using
* this pattern, but so far A2.0 has the most flexible and powerfull
* implementation
*/
public class Hooks {
int hookCount;
String hookNames[];
Vector hooksV[];
Object hooks[][];
Vector allModulesV;
Object allModules[];
private static final int dL=0;
public Hooks(int hookCount ) {
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util B ase64.java
Heya! Saw this thread and wanted to add a few (maybe un)related comments/questions: Of course, it would be nice to have the code factored out - maybe we can use digest for the MemoryRealm ( or other future realms ) too. ( another nice feature would be to support "unix"-like digests and mySQL-like password digests ). Again - as an util if possible :-) Costin I very much would love to see the digest stuff in a utility class. I'm guessing that at some point in the near future a user/password management tool will be asked for/proposed, and having the digesting code inside just the JDBCRealm kinda precludes this from being useful for the other current/future realms. The ability to add/update user information would also be extremely handy, and again, more useful if it is usable for different types of realm implementations. As a note these questions/comments apply equally to 3.x and 4.0 for me. Thanks again for the good work! David Weinrich
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/hooks Hooks.java
costin 00/12/27 23:14:45
Modified:src/share/org/apache/tomcat/core BaseInterceptor.java
Container.java
src/share/org/apache/tomcat/util/hooks Hooks.java
Log:
Next step in refactoring the hooks. Container is now using the Hook
util.
Revision ChangesPath
1.33 +8 -1
jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java
Index: BaseInterceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/BaseInterceptor.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- BaseInterceptor.java 2000/12/28 01:15:38 1.32
+++ BaseInterceptor.java 2000/12/28 07:14:44 1.33
@@ -513,6 +513,13 @@
public final int getDebug() {
return debug;
}
-
+
+/** Special method for self-registered hooks, intended to support
+ * a mechanism similar with Apache2.0 and further extensibility
+ * without interface changes.
+ */
+public int registerHooks() {
+ return DECLINED;
+}
}
1.42 +90 -101 jakarta-tomcat/src/share/org/apache/tomcat/core/Container.java
Index: Container.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Container.java,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- Container.java2000/12/26 23:10:55 1.41
+++ Container.java2000/12/28 07:14:44 1.42
@@ -60,6 +60,7 @@
package org.apache.tomcat.core;
import org.apache.tomcat.util.*;
+import org.apache.tomcat.util.hooks.*;
import java.io.*;
import java.net.*;
import java.util.*;
@@ -135,6 +136,7 @@
String methods[]=null;
public Container() {
+ initHooks();
}
/** Get the context manager
@@ -374,12 +376,6 @@
}
// Interceptors
-public static final int MAX_HOOKS=20;
-
-// Hook Ids - keep them in sync with PREDEFINED_I
-// ( static final for performance and to simplify code )
-// H_ is from "hook"
-
public static final int H_requestMap=0;
public static final int H_contextMap=1;
public static final int H_authenticate=2;
@@ -393,126 +389,119 @@
public static final int H_postRequest=10;
public static final int H_handleError=11;
public static final int H_engineInit=12;
+public static final int H_COUNT=14;
-public static final String PREDEFINED_I[]= {
- "requestMap", "contextMap", "authenticate",
- "authorize", "preService", "beforeBody",
- "newSessionRequest", "beforeCommit",
- "afterBody", "postService", "postRequest",
- "handleError",
- // special case - all interceptors will be added to the "context"
- // chain. We plan to use a simpler Event/Listener model for
- // all context hooks, since they don't have any performance requirement
- "engineInit" };
-
-// local interceptors - all interceptors added to this
-// container
-Vector interceptors[]=new Vector[ MAX_HOOKS ];
-
-// Merged interceptors - local and global ( upper-level ) interceptors
-BaseInterceptor hooks[][]=new BaseInterceptor[MAX_HOOKS][];
-
-// used internally
-private Vector getLocalInterceptors(int hookId) {
- if( interceptors[hookId]==null )
- interceptors[hookId]=new Vector();
- return interceptors[hookId];
+Hooks hooks=new Hooks();
+BaseInterceptor hooksCache[][]=null;
+BaseInterceptor allHooksCache[]=null;
+
+private void initHooks() {
+ hooks.registerHook( "requestMap", H_requestMap );
+ hooks.registerHook( "contextMap", H_contextMap );
+ hooks.registerHook( "authenticate", H_authenticate );
+ hooks.registerHook( "authorize", H_authorize );
+ hooks.registerHook( "preService", H_preService );
+ hooks.registerHook( "beforeBody", H_beforeBody );
+ hooks.registerHook( "newSessionRequest", H_newSessionRequest );
+ hooks.registerHook( "beforeCommit", H_beforeCommit );
+ hooks.registerHook( "afterBody", H_afterBody );
+ hooks.registerHook( "postService", H_postService );
+ hooks.registerHook( "postRequest", H_postRequest );
+ hooks.registerHook( "handleError", H_handleError );
+ hooks.registerHook( "engineInit", H_handleError );
}
-
+
+public Hooks getHooks() {
+ return hooks;
+}
+
/** Add the interceptor to all the hook chains it's interested
- in
-*/
+ * in
+ */
public void addInterceptor( BaseInterceptor bi ) {
bi.setContext( getContext() );
-
- for( int i=0; i
Url Encoding/Decoding and static resources
Hello again!
I have run into something of an issue with tomcat 3.2.1 and 4.0 and
urls/filenames that include funky/reserved characters ( the most
common/troublesome being # so far ). To fix this I read rfc1738
ftp://ftp.isi.edu/in-notes/rfc1738.txt on the 'proper' way to handle these
issues and found the answer in section 2.2 "URL Character Encoding Issues".
After fixing my webapp to encode these characters in the proper way, I
found that apache handled the urls and served out the resources correctly,
but Tomcat 3.2.1 and 4.0 didn't. Actually 4.0 handled the most common
character ( space or %20 ) but didn't handle other encoded characters, and
3.2.1 didn't handle any encoded characters ( if my memory serves me
correcly ). After digging through the source I was able to put minor changes
into a few files in 4.0 and one file in 3.2.1 that allowed both servers to
handle these URLs correctly for all of the test cases I have that previously
failed. I'll attach the patches for 4.0 now, I still want to go back over
the 3.2 patches one more time and make sure I didn't miss anything.
I attempted to handle all of the difficult situations that unencoding the
URL might pose ( inserting control characters and/or trying to get to a file
outside the appropriate area ), but there might be security/implementation
issues that I missed. Also, it could very well be the case that these are
not the right places to fix this particular problem, my apologies if I
missed the mark ;) Thanks again and I should have the 3.2 patch worked over
by tomorrow afternoon or so.
David Weinrich
--- ResourcesBase.java Tue Dec 26 23:36:29 2000
+++ ResourcesBaseEd.javaTue Dec 26 23:37:27 2000
@@ -961,9 +961,32 @@
* @param path Path to be normalized
*/
protected String normalize(String path) {
+ String normalized = path;
+
+ // Resolve encoded characters in the normalized path,
+ // which also handles encoded spaces so we can skip that later.
+ // Placed at the beginning of the chain so that encoded
+ // bad stuff(tm) can be caught by the later checks
+ while (true) {
+ int index = normalized.indexOf("%");
+ if (index 0)
+ break;
+ char replaceChar =
+ (char) ( Integer.parseInt(
+ normalized.substring( index + 1, index + 3 ), 16 ) );
+ // check for control characters ( values 00-1f and 7f-9f),
+ // return null if present. See:
+ // http://www.unicode.org/charts/PDF/U.pdf
+ // http://www.unicode.org/charts/PDF/U0080.pdf
+ if ( Character.isISOControl( replaceChar ) ) {
+ return null;
+ }
+ normalized = normalized.substring(0, index) +
+ replaceChar +
+ normalized.substring(index + 3);
+}
// Normalize the slashes and add leading slash if necessary
- String normalized = path;
if (normalized.indexOf('\\') = 0)
normalized = normalized.replace('\\', '/');
if (!normalized.startsWith("/"))
@@ -977,15 +1000,6 @@
normalized = normalized.substring(0, index) +
normalized.substring(index + 1);
}
-
- // Resolve occurrences of "%20" in the normalized path
- while (true) {
- int index = normalized.indexOf("%20");
- if (index 0)
- break;
- normalized = normalized.substring(0, index) + " " +
- normalized.substring(index + 3);
-}
// Resolve occurrences of "/./" in the normalized path
while (true) {
--- DefaultServlet.java Tue Dec 26 23:42:09 2000
+++ DefaultServletEd.java Tue Dec 26 23:41:52 2000
@@ -729,9 +729,33 @@
* @param path Path to be normalized
*/
protected String normalize(String path) {
+ String normalized = path;
+
+ // Resolve encoded characters in the normalized path,
+ // which also handles encoded spaces so we can skip that later.
+ // Placed at the beginning of the chain so that encoded
+ // bad stuff(tm) can be caught by the later checks
+ while (true) {
+ int index = normalized.indexOf("%");
+ if (index 0)
+ break;
+ char replaceChar =
+ (char) ( Integer.parseInt(
+ normalized.substring( index + 1, index + 3 ), 16 ) );
+ // check for control characters ( values 00-1f and 7f-9f),
+ // return null if present. See:
+ // http://www.unicode.org/charts/PDF/U.pdf
+ // http://www.unicode.org/charts/PDF/U0080.pdf
+ if ( Character.isISOControl( replaceChar ) ) {
+ return null;
+ }
+ normalized = normalized.substring(0, index) +
+ replaceChar +
+ normalized.substring(index + 3);
+}
+
// Normalize the slashes and add leading slash if
