Re: Portable SSL Support

[William Barker]

I was thinking of moving it to Http10Interceptor.getInfo, but otherwise that
was more or less what I was thinking.
- Original Message -
From: "jean-frederic clere" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, November 16, 2001 3:10 AM
Subject: Re: Portable SSL Support


> [EMAIL PROTECTED] wrote:
> >
> > On 14 Nov 2001, Eric Rescorla wrote:
> >
> > > Well, I suppose that since JDK 1.1.x didn't stop you from putting
> > > classes in java. I could do my own version of
> > > java.security.cert.X509Certificate. A little gross but perhaps
> > > the best plan. The alternative is to blatantly violate the spec
> > > in 1.1 and just deliver something else.
> >
> > I would say - don't worry about JDK1.1. Support for JDK1.1 is important
> > for embeded devices ( but even there, GCJ does have X509Certificate - it
> > already supports a large subset of JDK1.2, and that's included ).
> >
> > > > > > You have to use request.getAttribute() in the JSPs/servlets.
> > > > > Right, but that doesn't mean that we have to expose the SSLSupport
> > > > > interface. Instead we could break out each individual property
> > > > > we cared about into it's own attribute.
> > > >
> > > > To be consistant with 2.3 containers, I'd go with individually named
> > > > attributes.
> >
> > > Fine with me. Anyone object to this?
> >
> > Individual attributes are good, but if possible with lazy evaluation.
> >
> > The getInfo() callback in BaseInterceptor is supposed to do exactly
that -
> > allow you to lazy-evaluate expensive request fields, so only servlets
that
> > ask for the information will pay for it.
>
> In TC3.3:
> We have the following in Http10Interceptor.java:
>
> +++
> public Object getAttribute(String name) {
> if (name.equals("javax.servlet.request.X509Certificate")) {
> return(certcompat.getX509Certificates(socket));
> }
> return(super.getAttribute(name));
> }
> +++
>
> A note stored via request.setNote("SSLSupport",SSLSupport) somewhere in
> retrieved by getNote.
> The code ends to be:
> +++
> public Object getAttribute(String name) {
> if (name.equals("javax.servlet.request.X509Certificate")) {
> SSLSupport sslsupport = getNote("SSLSupport");
> if (sslsupport==null)
>   return(null);
> return(sslsupport.getX509Certificates(socket));
> }
> return(super.getAttribute(name));
> }
> +++
> Ideas?
>
> >
> > Costin
> >
> > --
> > To unsubscribe, e-mail:

> > For additional commands, e-mail:

>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Wrap an HttpServletRequest

[William Barker]

Craig's correct.  It's not legal in 3.x (and also won't work).

However, if all you want to do is to set parameters, you can simply add them
to the query string of the URL that you pass to getRequestDispatcher.
- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, November 14, 2001 9:09 AM
Subject: Re: Wrap an HttpServletRequest




On Wed, 14 Nov 2001, Diego del Río wrote:

> Date: Wed, 14 Nov 2001 10:16:16 -0300
> From: Diego del Río <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Wrap an HttpServletRequest
>
> Is there any way to wrap an HttpServletRequest in Tomcat 3.2.x and then
> forward the wrapped request to anoher servlet?
> We need a 'decorated request' with added functionality, more precisely, we
> need to add 'extra-parameters' to that request and then forward it to
> another servlet that process both the original and the added parameters.

In servlet 2.2 (Tomcat 3.x), it is not legal to wrap the request (or
response) that you pass to a request dispatcher -- the only choice you
have is to add request attributes.

In servlet 2.3 (Tomcat 4.0), it is legal to wrap the request and response,
as long as you subclass the provided wrapper base classes.  You can do
this for both request dispatchers and filters.

> Thanks,
> diego
>

Craig McClanahan


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[William Barker]

- Original Message -
From: "Eric Rescorla" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, November 14, 2001 9:17 AM
Subject: Re: Portable SSL Support


> jean-frederic clere <[EMAIL PROTECTED]> writes:
> > Eric Rescorla wrote:
> > > A few issues remain:
> > > (I) Is portability to JDK 1.1.x desirable/a requirement? Both the
> > > existing JSSE code and my new code rely upon java.security.cert.*
> > > which was introduced in JDK 1.2. Both JSSE and PureTLS provide more or
> > > less complete (less in the case of JSSE) certificate interfaces but
> > > they're of course different and we need a common interface presented
> > > to Tomcat. If JDK 1.1.x is a requirement I'll have to add a new
> > > abstraction layer, which can't inherit from java.security.cert because
> > > that didn't exist in 1.1. This isn't a problem (Simple Matter of
> > > Programming) but is only worth doing if necessary.
> >
> > With JDK 1.1.x and AJP a null is returned.
> > With JDK 1.1.x should the CC be returned as a String? (I thought it
was).
> It's certainly not in the JSSE code I was porting. That code
> didn't even compile without JDK 1.2.x.
>
> from build.xml:
>   unless="jdk12.present"/>
>
> In any case, we can do something far more sophisticated than a String
> if we want to, even with JDK 1.1.x.

If it wasn't mandated to be a java.security.cert.X509Certificate [] by
section 5.7 of the servlet spec :).

>
> > > (II) How to expose SSLSupport? Currently Request has access to
> > > SSLSupport but it's not obvious (at least to me) how best to
> > > expose this to the rest of Tomcat and to JSPs/servlets.
> >
> > You have to use request.getAttribute() in the JSPs/servlets.
> Right, but that doesn't mean that we have to expose the SSLSupport
> interface. Instead we could break out each individual property
> we cared about into it's own attribute.

To be consistant with 2.3 containers, I'd go with individually named
attributes.  That is what the application programmer will be expecting.  As
an example (from the 2.3 spec)

Table 3: Protocol Attributes
Attribute   Attribute Name
Java Type
cipher suite
javax.servlet.request.cipher_suite  String
bit size of the algo-rithmjavax.servlet.request.key_size
Integer

If there is an SSL certificate associated with the request, it must be
exposed by
the servlet container to the servlet programmer as an array of objects of
type
java.security.cert.X509Certificate and accessible via a ServletRequest
attribute of javax.servlet.request.X509Certificate.

> -Ekr
>
> --
> [Eric Rescorla   [EMAIL PROTECTED]]
> http://www.rtfm.com/
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Portable SSL Support

[William Barker]

I was originally leaning towards 2a, but Costin has convinced me of the
merits of 2b+1.  It is simplest and more generalizable to Ajp14/JNI in
j-t-c.  It also allows you to skip implementing the pooling/recycling stuff
(since it should be possible to reuse one instance per connector).

If you decide on 2a, like Costin, I'd prefer it as a property of the
SocketFactory (the base class can return null, since Ajp1x would use it's
own mechanism) rather than an interface.  However, it's your call.
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 8:52 AM
Subject: Re: Portable SSL Support
>
> > 3. Originally I'd intended to have ServerSockets return a class
> > that subclassed SSLSupport. E.g.
> >
> > class PureTLSSSLSocket extends SSLSocket implements SSLSupport {
> >...
> > }
> >
> > Unfortunately, as I should have seen immediately this isn't very
> > convenient. There's no way to make JSSE return a programmer-specified
> > subclass of SSLSocket instead of SSLSocket. I can of course make
> > PureTLS do so but that ties it inappropriately to Tomcat.
>
>
> > This leaves us with two alternatives:
> > (1) Create a wrapper class for SSLSocket:
> >
> > class SSLSocketWrapper extends Socket implements SSLSupport {
> >   Socket internal;
> >
> >   SSLSocketWrapper(Socket sock) {
> > internal=sock;
> >   }
> >
> >   // Forwarding for all the relevant socket methods
> > }
> >
> > In general I hate class forwarding so I'm strongly tempted not to
> > do this.
>
> A don't like this either ( and I didn't like too much the idea
> of returning a socket that implements SSLSupport either ).
>
> What I would do is:
>
> SSLSupport {
>String getFoo( Object socket, ... );
>
> }
>
> In other words, you pass the socket from which the SSLSupport object will
> extract the information. ( it doens't have to be a socket - it can also be
> an Ajp14Connection ). I think this is quite flexible and doesn't have too
> much overhead
>
> ( but it's your choice, of course - you are writing the code :-)
>
>
> > (2) Extend/generalize the socketFactory to include an SSLSupport
> > factory. This is actually pretty convenient since the relevant
> > section of code, Http10Interceptor already has access to
> > the socketFactory information via inheritance from
> > PoolTcpConnector. This could be done in several ways
> >
> > (a) Require that all SocketFactorys that produce SSL sockets implement
> >
> > interface SSLSupportFactory {
> > public SSLSupport createSSLSupport(Socket socket);
> > }
>
> That's fine too. For Ajp connectors we could have a different mechansim to
> create the SSLSupport.
>
>
> > (b) Have a second factory object in PoolTcpConnector and use reflection
> > to look it up. I don't much like this idea because it implies that
> > you can mix and match SocketFactories with SSLSupport classes
> > which of course you cannot.
>
> Well, I like this idea - combined with the first one ( reversed ) :-)
>
> I.e:
> - SSLSupport act as a factory for SSLSocketFactories
> - user will set only the SSLSupport class, which will create the socket
> factory
> - PoolTcpConnector will just have a method 'setSSLSupport'
> - SSLSupport will be an abstract class, and will contain code to do
> reflection and create the exact implementation
> - Code using SSL will call SSLSupport.getSSLSupport() ( and maybe
> setProperty, etc ), then set it on PoolTcpConnector ( if sockets are
> used), etc.
> - SSLSupport should be independent of tomcat ( you may noticed that
> tomcat.util is compiled without any other tomcat class in classpath,
> i.e. it can't have any dependencies on any internal tomcat class ! )
>
>
> BTW, my personal preference is to avoid too many interfaces - in general I
> prefer abstract classes if it is possible. At least until it becomes clear
> we need a certain abstraction, otherwise we end up with something too
> complex. For most people ( other than the author ) it is hard to
> 'navigate' around dozens of interfaces and base classes and hierarchies (
> at least it is for me )
>
> Costin
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, t

Re: [VOTE] Release Plan for Tomcat 3.3 (final release)

[William Barker]

For what it's worth (since I can't vote), I agree with Jon.  TC3.3 hasn't
had a long enough beta cycle yet to push through an RC cycle this fast.  As
it is, I'm going to be lucky to have time to install RC1 before RC2 comes
out.  Keeping up with 4.0 isn't a good enough reason, since I'm sure that
there are plenty of people like me who can't even think of moving to 4.0
until it has release-quality connectors.
- Original Message -
From: "Jon Stevens" <[EMAIL PROTECTED]>
To: "tomcat-dev" <[EMAIL PROTECTED]>
Sent: Monday, September 10, 2001 12:38 PM
Subject: Re: [VOTE] Release Plan for Tomcat 3.3 (final release)


> on 9/10/01 9:12 AM, "Christopher Cain" <[EMAIL PROTECTED]> wrote:
>
> >
> >> = Tomcat 3.3 Final Release Plan Ballot =
> >> [ ] +1I am in favor of this plan, and will help
> >> [ ] +0I am in favor of this plan, but am unable to help
> >> [ ] -0I not in favor of this plan
> >> [X] -1I am opposed to this plan, and my reason(s) are:
> >> 
>
>

IGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&e
>
mail2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&chang
>
edin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Tomcat+3&short
>
_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&bug_fil
>
e_loc=&bug_file_loc_type=substring&keywords=&keywords_type=anywords&field0-0
> -0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+
sa
> me+sort+as+last+time>
>
> Essentially a query for all new/assigned/reopened bugs in Tomcat 3.
>
> Is there also a recursive test to make sure that all 3.2.x reported/fixed
> bugs are also fixed in 3.3?
>
> -jon
>
>


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

[PATCH] Potential security problem with '?' in jsp file name TC3.3B1

[William Barker]

Using:
 Apache 1.3.17
TC3.3 B1
 Ajp13
Java 1.3.1

making the request http://myserver/%3f%41%3d%42.jsp was interpreted as a
request for the file "/?A=B.jsp".  JspInterceptor then happily creates a
page containing the contents of the ROOT directory.  The attached patch
forbids such silliness.

 JspInterceptor.diff

[PATCH] ajp13 logs 500 code on stop button

[William Barker]

This is only a cosmetic patch, so it may not make the cut for TC3.3, but
the diff is against TC3.3B1.  At the moment, when the user hits the "stop"
button, it shows up in the Apache logs with a status code of 500 (regardless
of the status code returned by Tomcat).  With this patch, the Apache logs
show the status code returned by Tomcat (hopefully 200 in most cases).  The
fail-over logic is otherwise unchanged.

 jk_ajp13_worker.diff

[PATCH] Smart mappings + map-root confuses Apache TC3.3B1

[William Barker]

The configuration:
 

causes ApacheConfig to output a line of the form:
Alias / /path/to/ROOT

which makes Apache very unhappy when trying to find static files.

One alternative to the attached patch would be to simply output a
DocumentRoot directive for this special case, but I thought that that would
be more error-prone.

 ApacheConfig.diff

[PATCH] Ajp13 wrong Response

[William Barker]

This fixes the problem reported by Angel Aray in thread 23795.  The diff is
against TC3.3 M4.  What was happening is that the user hitting the "stop"
button in the browser was invoking the re-try broken connection logic.  This
totally freaks out the proxy server who now thinks that the re-sent page is
actually the page for a different request.

 jk_ajp13_worker.diff

[PATCH] Exporting servlet-mappings to Apache/mod_jk TC3.3-M4

[William Barker]

   I don't really expect this to be approved for inclusion, since it relies
on ApacheConfig having too much knowledge about Context internals.  I'm
submitting it primarily to demonstrate to the ajp14/warp crowd that it is
possible to auto-generate mappings short of "JkMount /my-app/* ajp13".

 ApacheConfig.diff

[PATCH] JspInterceptor compilation class path wrong TC3.3M2

[William Barker]

   When setting the classpath for compilation, JspInterceptor (or more
correctly, JasperLiaison) includes the "container" and excludes the "apps".
This sort of defeats the purpose of having the "apps" in the first place.
I've patched my copy of JspInterceptor.java as follows:

*** JspInterceptor.java.origTue Apr  3 12:56:11 2001
--- JspInterceptor.java Thu Apr 26 13:52:45 2001
***
*** 723,730 
  Jdk11Compat jdkProxy=Jdk11Compat.getJdkCompat();
  URL serverCP[];
  URL commonCP[];
! serverCP=jdkProxy.getParentURLs(this.getClass().getClassLoader());
! commonCP=jdkProxy.getURLs(this.getClass().getClassLoader());
if( serverCP!=null )
cpath+=separator+extractClassPath(serverCP);
if( commonCP!=null )
--- 724,733 
  Jdk11Compat jdkProxy=Jdk11Compat.getJdkCompat();
  URL serverCP[];
  URL commonCP[];
!
! ClassLoader parentLoader =
ctx.getContextManager().getParentLoader();
! serverCP=jdkProxy.getURLs(parentLoader);
! commonCP=jdkProxy.getParentURLs(parentLoader);
if( serverCP!=null )
cpath+=separator+extractClassPath(serverCP);
if( commonCP!=null )

[PATCH] bufferSize overflows in BodyContentImpl TC3.3M2

[William Barker]

The bufferSize variable in BodyContentImpl is declared as an int.  This
results in an integer overflow very quickly for even moderately big output.
(Think displaying the results of a SQL table as a HTML table).  I imagine
that the ultimate solution will be to declare it as a long, but in the mean
time...
*** BodyContentImpl.java.orig   Tue Apr  3 16:46:37 2001
--- BodyContentImpl.javaTue Apr  3 16:47:15 2001
***
*** 110,119 
  char[] tmp = null;

//XXX Should it be multiple of DEFAULT_BUFFER_SIZE??
!
if (len <= Constants.DEFAULT_BUFFER_SIZE) {
tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
!   bufferSize = bufferSize * 2;
} else {
tmp = new char [bufferSize + len];
bufferSize += len;
--- 110,119 
  char[] tmp = null;

//XXX Should it be multiple of DEFAULT_BUFFER_SIZE??
! len += Constants.DEFAULT_BUFFER_SIZE -
(len%Constants.DEFAULT_BUFFER_SIZE);
if (len <= Constants.DEFAULT_BUFFER_SIZE) {
tmp = new char [bufferSize + Constants.DEFAULT_BUFFER_SIZE];
! bufferSize += Constants.DEFAULT_BUFFER_SIZE;
} else {
tmp = new char [bufferSize + len];
bufferSize += len;

[PATCH] JspInterceptor can't find jsp file in TC3.3M2

[William Barker]

   If you use a  in your web.xml file, JspInterceptor
attempts to compile the mapped name rather than the actual jsp file.  I've
patched my copy of tomcat by:
*** JspInterceptor.java.origTue Apr  3 12:56:11 2001
--- JspInterceptor.java Tue Apr  3 12:59:58 2001
***
*** 585,590 
--- 585,591 
try {
Options options=new JasperOptionsImpl(args);
JspCompilationContext ctxt=createCompilationContext(req,
+
jspFile,
options,

mangler);
JavaCompiler javaC=createJavaCompiler( options );
***
*** 747,758 
  }

  private JspCompilationContext createCompilationContext( Request req,
Options opt,
Mangler mangler)
  {
JasperEngineContext ctxt = new JasperEngineContext();
ctxt.setServletClassName( mangler.getClassName());
!   ctxt.setJspFile( req.servletPath().toString());
ctxt.setClassPath( computeClassPath( req.getContext()) );
  //System.out.println("computeClasspath:"+ctxt.getClassPath());
ctxt.setServletContext( req.getContext().getFacade());
--- 748,760 
  }

  private JspCompilationContext createCompilationContext( Request req,
+ String
jspFile,
Options opt,
Mangler mangler)
  {
JasperEngineContext ctxt = new JasperEngineContext();
ctxt.setServletClassName( mangler.getClassName());
!   ctxt.setJspFile(jspFile);
ctxt.setClassPath( computeClassPath( req.getContext()) );
  //System.out.println("computeClasspath:"+ctxt.getClassPath());
ctxt.setServletContext( req.getContext().getFacade());

Re: TC3.3m1 Possible bug with session.invalidate

[William Barker]

Title: Re: TC3.3m1 Possible bug with session.invalidate



The place to look is 
src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java.  Or, 
better, get the latest version of this file since the bug was fixed about two 
weeks ago.

  - Original Message - 
  From: 
  Dunlop, 
  Aaron 
  To: '[EMAIL PROTECTED]' 
  Sent: Tuesday, March 06, 2001 2:11 
  PM
  Subject: Re: TC3.3m1 Possible bug with 
  session.invalidate
  
  I seem to be having a similar problem. My app also uses 
  session information to track logins, and calls 
  session.invalidate() when a user logs out. 
  So far I'm seeing that if a user starts up a new browser, logs 
  in, logs out, and attempts to login again as a different user, they get the 
  session from their first login as if they 
  had never logged out. Logging off again appears to fix the 
  problem, and subsequent logins from the browser work 
  fine. The problem recurs when a new browser is started. 
  I don't see any references to this problem in Bugzilla, so 
  I'll dive into the code and see what I can find. But 
  if by chance someone has already fixed this problem somewhere, 
  please let me know. 
  --- Environment: 
  Server: Tomcat 3.3m1 standalone on 
  Solaris 2.7 IBM JDK 1.2.2 
  Client: NT 4.0 SP 5 IE 5.5 or Netscape 4.7 - same symptoms 
  Thanks, Aaron Dunlop [EMAIL PROTECTED] 
  -- 
  From: [EMAIL PROTECTED] 
  Hi, 
  I seem to be having a problem with session.invalidate(). I'm 
  using this for users to log out of my web site but it 
  seems to take two attemps before the user is properly 
  logged out! 
  I am using JDBCRealms for authentication BTW. 
  I have set up a simple four page web site: 
  test/jsp/index.jsp  front page <% response.setHeader("Cache-Control","no-cache"); //HTTP 1.1 
  response.setHeader("Pragma","no-cache"); //HTTP 1.0 
  response.setDateHeader ("Expires", 0); //prevents caching at 
  the proxy server %>   <%=request.toString()%> <%=request.getSession (false)%> <%=request.getRemoteUser()%> <%=request.getUserPrincipal()%> 
  Login 

  
  test/jsp/protected/index.jsp --- protected page 
  <% response.setHeader("Cache-Control","no-cache"); //HTTP 1.1 
  response.setHeader("Pragma","no-cache"); //HTTP 1.0 
  response.setDateHeader ("Expires", 0); //prevents caching at 
  the proxy server %>   
  <%=request.toString()%> <%=request.getSession (false)%> you are currently logged in as <%= request.getRemoteUser() 
  %> Logout 

  
  test/jsp/protected/logout.jsp --- logout page <% response.setHeader("Cache-Control","no-cache"); //HTTP 1.1 
  response.setHeader("Pragma","no-cache"); //HTTP 1.0 
  response.setDateHeader ("Expires", 0); //prevents caching at 
  the proxy server %>   <%=request.toString()%> <%=request.getSession (false)%> <%=request.getRemoteUser()%> <%=request.getUserPrincipal()%> <%  
  session.invalidate (); %> <%=request.getSession (false)%> <%=request.toString()%> <%=request.getRemoteUser()%> <%=request.getUserPrincipal()%> 
  home.   
  test/jsp/login/login.jsp --- login page used by FORM based 
  authentication.   Login page 
   
   
   Username:   Password: 
        

  
  The problem occurs like this: The 
  first time around the request for protected/index.jsp is detected and 
  you have to log in. >From 
  there, access the logout page which does a <% 
  session.invalidate();%>. Then back to 
  jsp/index.jsp, try and access the protected page from here -- 
  straight in as still authenticated. Accessing the log out page again, actually logs out this time! 
  
  Is this a known problem? Any possible work arounds? 

  Thanks, Sam. PS. This work fine on TC3.2.1 

Re: Tag Handler Pooling Clarification

[William Barker]

My reading of the spec is that after calling Tag.release, the tag handler
could be safely put back into the pool. However calling Tag.release after
doEndTag isn't mandatory.  If the compiler is smart enough, it may re-use a
tag without releasing it first if the second invocation uses a super-set of
the first ones attributes.  Granted, section 10.3 of the spec forgets to
address this point , but my reading is that it should say:
// loop
}
  // put d back to pool
  }
- Original Message -
From: "Casey Lucas" <[EMAIL PROTECTED]>
To: "tomcat dev" <[EMAIL PROTECTED]>
Sent: Tuesday, March 06, 2001 9:00 AM
Subject: Tag Handler Pooling Clarification


>
> Sorry for the long message, but I'm a bit unclear on some Tag related
> spec details.  I need to make sure I have a clear understanding before
> I start thinking about tag handler reuse implementation.
>
>
> My original understanding of Tag.release was that it was always called
after
> a tag handler was used -- after doEndTag.  After calling release, the JSP
> container could then put the tag handler back into a pool for reuse.  So,
> I was under the impression that a tag handler could be treated simply as
> a pooled resource.
>
> Based on my understanding, all of our code simply set tag handler
attributes
> to their default values in the release method.  By doing this we set the
tag
> handler to a "default" or "initialized" state.  Subsequently,
setPageContext,
> various setters, etc. could be called and the whole tag use process would
> proceed again.
>
> But, after a more careful reading of the tag sections of the JSP 1.2 spec,
it
> appears that tag reuse can only occur when tags have the same set of
> attributes that are initialized in the JSP.  Specifically, in section
10.1.1
> under the "Lifecycle" section, bullet [3] states:
>
>   Note that since there are no guarantees on the state of the properties,
>   a tag handler that had some optional properties set can only be reused
>   if those properties are set to a new (known) value.  This means that
>   tag handlers can only be reused within the same "Att-Set" (set of
>   attributes that have been set).
>
>
> This part of the spec could be interpreted to mean that tag handlers
> should only be reused if they have the same set of attributes.  For
example,
> given the following JSP fragment, two different tag1 handlers would
> have to be used (instead of reusing the handler):
>
> 
>
> 
>
>
> I hope that I'm misunderstanding something.  I'd much prefer that the
> JSP container can rely on the handler's release method to reset the
> handler to a known state and simply start the tag process over again
> (setPageContext, setters, etc.)  Such an assumption would greatly
> simplify a pooling strategy.
>
> Can anyone provide clarification?
>
> -Casey
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[PATCH] Exporting Servlet mappings for mod_jk

[William Barker]

It was getting to be too much work to keep my web.xml files synced with
httpd.conf, so I got ApacheConfig.java to do it for me.  The following is
for Tomcat 3.3M1:
*** ApacheConfig.java.orig  Thu Mar  1 16:40:46 2001
--- ApacheConfig.java   Thu Mar  1 16:38:26 2001
***
*** 328,337 
  mod_jk.println("#");
  mod_jk.println("# The following line mounts all JSP files and
the/servlet/ uri to tomcat");
  mod_jk.println("#");
mod_jk.println("JkMount " + path +"/servlet/* " +
JkMount[jkConnector]);
mod_jk.println("JkMount " + path +"/*.jsp " +
JkMount[jkConnector]);

-
// Deny serving any files from WEB-INF
  mod_jk.println();
  mod_jk.println("#");
--- 328,345 
  mod_jk.println("#");
  mod_jk.println("# The following line mounts all JSP files and
the/servlet/ uri to tomcat");
  mod_jk.println("#");
+ /*
mod_jk.println("JkMount " + path +"/servlet/* " +
JkMount[jkConnector]);
mod_jk.println("JkMount " + path +"/*.jsp " +
JkMount[jkConnector]);
+ */
+Enumeration ctxMaps = context.getContainerLocations();
+while(ctxMaps.hasMoreElements()) {
+   String cxpath = (String)ctxMaps.nextElement();
+   if(!cxpath.startsWith("/"))
+  cxpath = "/"+cxpath;
+   mod_jk.println("JkMount " + path + cxpath +" "+
JkMount[jkConnector]);
+}

// Deny serving any files from WEB-INF
  mod_jk.println();
  mod_jk.println("#");



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Bugzilla #512 is Bunk

[William Barker]

JkWorkersFiles is the main problem inside of a VirtualHost.  I don't know
about JkLogFile. JkMount is legal inside of a VirtualHost.
- Original Message -
From: "Stephen Jones" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, February 28, 2001 8:08 PM
Subject: Bugzilla #512 is Bunk


> The following bug is not a bug:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=512
>
> In httpd.conf, you cannot do this:
>
> 
>   normal config for VirtualHost ...
>  Include /usr/local/jakarta-tomcat/conf/mod_jk.conf-auto
> 
>
> There are three main purposes of including mod_jk.conf-auto:
>
> (1) To get the mod_jk Apache Module loaded, as follows:
>   LoadModule jk_module libexec/mod_jk.so
>
> (2) To configure Apache for your Tomcat Contexts using Alias, Location,
> and Directory Apache Directives
>
> (3) To configure mod_jk itself using all the directives starting with Jk
> (JkWorkersFile, JkLogFile, JkMount, etc).
>
> The first (1) Apache directive is the problem: the LoadModule directive
> is illegal within the VirtualHost context.
> (See http://httpd.apache.org/docs/mod/mod_so.html#loadmodule )
>
> The directives in (2) are definitely legal, but I don't know about those
> in (3) since they are custom. Does anyone know whether these would work
> within the VirtualHost context?
>
> The bug was reported by someone using Apache 1.3.14; they recieved a
> core dump dereferencing a null pointer to something that was supposed to
> contain Apache configuration info (a jk_server_conf_t).
> I am using Apache 1.3.17; I recieved this polite and informative (wow,
> from open source software?) error message:
>
> sudo /usr/local/apache/bin/apachectl startssl
> Syntax error on line 8 of /usr/local/tomcat/conf/mod_jk.conf-auto:
> LoadModule cannot occur within  section
> /usr/local/apache/bin/apachectl startssl: httpd could not be started
>
> Provided that the custom directives (3) will work within a VirtualHost
> context, the solution to this problem is to create a custom
> configuration file based on mod_jk.conf-auto, move the LoadModule
> directive into it, and then Include it from within your VirtualHost
> context.
>
> If the directives (3) do work, another option would be for Tomcat to
> change the code to not generate the LoadModule directive, which prevents
> this level of configurability, and just make people type it in.
>
> Hope this is helpful,
> Steve Jones
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [Security Issue] Sessions are visible across multiple clients

[William Barker]

It has more to do with a bug in SimpleSessionStore.java.  It recycles the
session on create, so then the instance is re-used for the next new session.
I've patched it via:
*** SimpleSessionStore.java.origMon Feb 26 14:59:53 2001
--- SimpleSessionStore.java Wed Feb 28 09:36:40 2001
***
*** 426,432 
if (session == null) {
session = new ServerSession();
session.setManager( this );
-   recycled.put( session );
}

// XXX can return MessageBytes !!!
--- 426,431 

- Original Message -
From: "GOMEZ Henri" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, February 28, 2001 8:59 AM
Subject: RE: [Security Issue] Sessions are visible across multiple clients


> Probably partially resolved by the patch I forward previously.
> From M. Frey
>
> La prise de conscience de votre propre ignorance est un grand pas vers la
> connaissance.
> -- Benjamin Disraeli
>
>
> >-Original Message-
> >From: Amrhein, Thomas [mailto:[EMAIL PROTECTED]]
> >Sent: Wednesday, February 28, 2001 5:59 PM
> >To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> >Subject: [Security Issue] Sessions are visible across multiple clients
> >
> >
> >Hi all,
> >
> >one session can be visible on multiple clients!!
> >
> >THIS IS A BIG SECURITY PROBLEM!
> >
> >Someone opens his webbrowser and has the session of somebody else.
> >So critical data could be viewed without permission.
> >Somebody can act as somebody else.
> >
> >What's wrong with tomcat's session-handling?
> >
> >I wrote a web application which can reproduce this.
> >
> >I'm working with Tomcat 3.3m1 on WinNT4.
> >On 3.2 I have the same problems sometimes with our application
> >but it is not reproducable there.
> >
> >To reproduce this:
> >- put sessiontest.war in %TOMCAT_HOME%/webapps/
> >- start Tomcat
> >- open browser1 (Netscape 4.7 or IE5) on machine1 (close it
> >before if it's
> >already open)
> >- locate browser1 on http://yourtomcat/sessiontest/index.jsp
> >(a cookie will
> >be set)
> >- browser1: login with name for example 'Testuser1'
> >- browser1: show settings (The name is displayed)
> >- open browser2 on machine2 (close it before if it's already open)
> >- locate browser2 on http://yourtomcat/sessiontest/index.jsp
> >(a cookie will
> >be set)
> >
> >Browser2 now sees the same content like browser1 (logged in as
> >Testuser1).
> >Look for the sourcecode in the .war. All objects are session-bound.
> >Normally you should not be logged in.
> >Remember that you are on different machines! They should have different
> >cookies, different
> >sessions, different usernames.
> >Sometimes but not often, they have the same Session-ID (I can
> >not reproduce
> >this).
> >
> >Bug #723: sessions are not properly recycled
> >Perhaps my issue belongs to this.
> >
> >I've seen different bugs reported but not solved belonging to
> >session-handling.
> >#131,152,183,189,267,429,723,731
> >
> >Can somebody reproduce this behaviour somewhere else?
> >And can this behaviour also happen in Tomcat 3.2/3.2.1 (I
> >don't know the
> >code)?
> >
> >regards,
> >
> >Thomas
> >
> >PS: I'm new to tomcat-dev-mailinglist (two or three hours) to
> >stay tuned.
> >Perhaps it's already discussed and patched. Please inform me.
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[PATCH] JspInterceptor losing jsp file name - Tomcat 3.3M1

[William Barker]

When a JSP file is specified via a servlet-mapping in the web.xml file,
tomcat tries to compile the mapping rather than the JSP file.
*** JspInterceptor.java.origTue Feb 27 18:58:50 2001
--- JspInterceptor.java Tue Feb 27 18:59:10 2001
***
*** 585,590 
--- 585,591 
try {
Options options=new JasperOptionsImpl(args);
JspCompilationContext ctxt=createCompilationContext(req,
+
jspFile,
options,

mangler);
JavaCompiler javaC=createJavaCompiler( options );
***
*** 747,758 
  }

  private JspCompilationContext createCompilationContext( Request req,
Options opt,
Mangler mangler)
  {
JasperEngineContext ctxt = new JasperEngineContext();
ctxt.setServletClassName( mangler.getClassName());
!   ctxt.setJspFile( req.servletPath().toString());
ctxt.setClassPath( computeClassPath( req.getContext()) );
  //System.out.println("computeClasspath:"+ctxt.getClassPath());
ctxt.setServletContext( req.getContext().getFacade());
--- 748,760 
  }

  private JspCompilationContext createCompilationContext( Request req,
+   String jspFile,
Options opt,
Mangler mangler)
  {
JasperEngineContext ctxt = new JasperEngineContext();
ctxt.setServletClassName( mangler.getClassName());
!   ctxt.setJspFile( jspFile);
ctxt.setClassPath( computeClassPath( req.getContext()) );
  //System.out.println("computeClasspath:"+ctxt.getClassPath());
ctxt.setServletContext( req.getContext().getFacade());



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup Main.java

[William Barker]

This is a very nice feature.  Just for cleanliness, you might want to remove
the "tomcat.cp" property logic at line #426.
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 26, 2001 1:42 AM
Subject: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/startup
Main.java


> nacho   01/02/26 01:42:30
>
>   Modified:src/share/org/apache/tomcat/startup Main.java
>   Log:
>   Added :
>
>   org.apache.tomcat.common.classpath
>   org.apache.tomcat.shared.classpath
>
>   System properties to set the shared and common classpath, this are added
prior
>   to adding the internal lib directories ..
>
>   Submitted by Mel Martinez [[EMAIL PROTECTED]]
>
>   Revision  ChangesPath
>   1.26  +222 -85
jakarta-tomcat/src/share/org/apache/tomcat/startup/Main.java
>
>   Index: Main.java
>   ===
>   RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/startup/Main.java,v
>   retrieving revision 1.25
>   retrieving revision 1.26
>   diff -u -r1.25 -r1.26
>   --- Main.java 2001/02/10 19:17:28 1.25
>   +++ Main.java 2001/02/26 09:42:30 1.26
>   @@ -1,4 +1,4 @@
>   -/*
>   +/* $Id: Main.java,v 1.26 2001/02/26 09:42:30 nacho Exp $
> * 
> *
> * The Apache Software License, Version 1.1
>   @@ -69,22 +69,101 @@
>import org.apache.tomcat.util.IntrospectionUtils;
>import org.apache.tomcat.util.compat.Jdk11Compat;
>
>   -// Depends:
>   -// JDK1.1
>   -// tomcat.util.IntrospectionUtils, util.compat
>
>/**
>   - * Starter for Tomcat.
>   - *
>   - * This is a replacement/enhancement for the .sh and .bat files - you
can
>   - * use JDK1.2 "java -jar tomcat.jar", or ( for jdk 1.1 ) you just need
to
>   - * include a single jar file in the classpath.
>   - *
>   - * @author Costin Manolache
>   - * @author Ignacio J. Ortega
>   - *
>   + Starter class for Tomcat.
>   + 
>   + This is a replacement/enhancement for the .sh and .bat files - you can
>   + use JDK1.2 "java -jar tomcat.jar", or ( for jdk 1.1 ) you just need to
>   + include a single jar file in the classpath.
>   + 
>   + This class creates three class loader instances:
>   + 
>   + a 'common' loader to be the parent of both the server
>   + container and also webapp loaders.
>   + a 'shared' loader to load classes used by all webapps, but
>   + not the servlet engine.
>   + a 'server' loader exclusively for the tomcat servlet engine.
>   + 
>   + Both the 'shared' loader and 'server' loader have the common loader as
>   + the parent class loader.  The class path for each is assembled like
so:
>   + 
>   + common - all elements of the
org.apache.tomcat.common.classpath
>   +   property plus all *.jar files found in
${TOMCAT_HOME}/lib/common/.
>   + shared - all elements of the
org.apache.tomcat.shared.classpath
>   +   property plus all *.jar files found in
${TOMCAT_HOME}/lib/shared/.
>   + server - all jar files found in ${TOMCAT_HOME}/lib, plus the class
>   +   folder ${TOMCAT_HOME}/classes and finally also the utility jar
>   +   file ${JAVA_HOME}/lib/tools.jar.
>   + 
>   + After creating the above class loaders, this class instantiates,
initializes
>   + and starts an instance of the class
org.apache.tomcat.startup.Tomcat.
>   + 
>   + @author Costin Manolache
>   + @author Ignacio J. Ortega
>   + @author Mel Martinez [EMAIL PROTECTED]
>   + @version $Revision: 1.26 $ $Date: 2001/02/26 09:42:30 $
> */
>public class Main {
>   +
>   +/**
>   +name of configuration property to set (using the -D option
at
>   +startup or via .properties file) to specify the classpath
>   +to be used by the ClassLoader shared amongst all web
applications
>   +(but not by the servlet container).  Specify this string as
>   +normal file paths separated by the path.seperator delimiter
for
>   +the host platform.  Example (unix):
>   +
>   +* org.apache.tomcat.shared.classpath =
/home/mypath/lib/mylib.jar: \
>   +*
/home/mypath/classes/
>   +
>   +*/
>   +public static final String TOMCAT_SHARED_CLASSPATH_PROPERTY =
>   +"org.apache.tomcat.shared.classpath";
>   +
>   +/**
>   +the classpath shared among all web apps (in addition to any
>   +jar files placed directly in $TOMCAT_HOME/lib/shared/).
>   +*/
>   +public static final String TOMCAT_SHARED_CLASSPATH;
>   +
>   +/**
>   +name of configuration property to set (using the -D option
at
>   +startup or via .properties file) to specify the classpath
>   +to be used by the ClassLoader common to both the servlet
engine
>   +and all web applications.  Specify this string as
>   +normal file paths separated by the path.seperator delimiter
for
>   +  

Bug in Request.isUserInRole - Tomcat 3.3

[William Barker]

   Request.isUserInRole doesn't allow an interceptor to DECLINE (and is
inconsistent with Context).  The following change to
org/apache/tomcat/core/Request.java brings it in line:
488c488
<   if ( status != 0 ) {
---
>   if ( status != BaseInterceptor.DECLINED ) {
492c492
<   return status==0;
---
>   return status==BaseInterceptor.OK;



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

ClassPath problem with Tomcat 3.3

[William Barker]

   It seems that the only way to add files to the CLASSPATH in 3.3 is via
the tomcat.cp property, but it doesn't seem to be working quite right.
Below is the patch to org/apache/tomcat/startup/Main.java that works for me.

133,134c133,134
<   if( ! base.endsWith( "/" ) )
<   base=base + "/";
---
> //if( ! base.endsWith( "/" ) )
> //base=base + "/";
136c136
<   File f = new File(base + file);
---
>   File f = new File(base , file);
140c140
<   return new URL( "file", null, path );
---
> return new URL( "file", null, path );
193c193,205
< URL[] commonClassPath=getURLs(getClassPathV(getCommonDir()));
---
> urlV = getClassPathV(getCommonDir());
>   // add CLASSPATH
>   String cpath=System.getProperty( "tomcat.cp");
>   if( cpath!=null ) {
>   System.out.println("Extra CLASSPATH: " + cpath);
>   String pathSep=System.getProperty( "path.separator");
>   StringTokenizer st=new StringTokenizer( cpath, pathSep );
>   while( st.hasMoreTokens() ) {
>   String path=st.nextToken();
>   urlV.addElement( getURL( "/",path ));
>   }
>   }
> URL[] commonClassPath=getURLs(urlV);
287,297d298
<   // add CLASSPATH
<   String cpath=System.getProperty( "tomcat.cp");
<   if( cpath!=null ) {
<   System.out.println("Extra CLASSPATH: " + cpath);
<   String pathSep=System.getProperty( "path.separator");
<   StringTokenizer st=new StringTokenizer( cpath, pathSep );
<   while( st.hasMoreTokens() ) {
<   String path=st.nextToken();
<   urlV.addElement( getURL( path, "" ));
<   }
<   }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]