SendMailFactory.java breaks compile

[Stuart Roebuck]

I've just tried to compile the latest CVS of Tomcat 4 and I'm missing some 
classes trying to compile SendMailFactory.java.

/Users/stuart/OpenSource/jakarta-tomcat-4.0/catalina/src/share/org/apache/
naming/factory/SendMailFactory.java:0: Class javax.activation.DataSource 
not found in class javax.mail.internet.MimePartDataSource.

I tried dropping Java Mail 1.2 into the classpath but this doesn't help.

Am I missing something obvious?

Stuart.

-
Stuart Roebuck  [EMAIL PROTECTED]
Lead Developer   Java, XML, MacOS X, XP, etc.
ADOLOS http://www.adolos.com/

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Steve Downey]

It's one of the alternate names for Abstract Factory, from the GoF book. AKA
toolkit. 

The idea is that you have a an abstract class with methods such as
createThing1 and createThing2, which return abstract Thing1s and Thing2s. A
concrete implementation of the factory, xFactory,  returns an xThing1 and an
xThing2, and a yFactory returns yThing1 and yThing2.

A classic example is GUI widgets, where you might have MotifButton,
MotifScrollbar, MotifWindow, ..., or Win32Button, Win32Scrollbar,
Win32Window, ..., or GtkButton, GtkScrollbar, GtkWindow, ...

Here we have CommandLineMangler, CommmandLineContext, CommandLineCompiler,
and JspMangler, JspEngineContext, JspCompiler, ...

They don't seem to be pure mix and match. That is, it doesn't necessarily
make sense to use an XCompiler with an XContext, although it might. So the
overhead of having to create a new Factory implementation for a new
combination or style isn't that excessive.





> -Original Message-
> From: Alex Fernández [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 30, 2001 2:49 AM
> To: [EMAIL PROTECTED]
> Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
> 
> 
> Hi Steve!
> 
> Steve Downey wrote:
> > Perhaps a Kit pattern is in order?
> 
> Wow, a Kit pattern. I never heard of that one (or never got 
> that far in
> the Patterns books :)
> 
> Is it a standard one? If so, I'll check it out later at home.
> 
> Un saludo,
> 
> Alex.
> 
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Mel Martinez]

--- Steve Downey <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > 
> > On Thu, 29 Mar 2001, Mel Martinez wrote:
> > 
> > > activities that should be orthogonal.  The only
> > > dependency should be that the Compiler is a
> consumer
> > > of the products of the Mangler.
> > 
> > +1
> 
> If we treat the embedded implementation of Mangler
> as a separate class,
> which I think is a good idea, each style of JSP
> compilation works with a
> triad of somewhat dependant classes. An X-Compiler,
> an X-Context and an
> X-Mangler. If we're playing games with the name of
> the generated class, like
> decorating it with a version number, then some other
> part of the system
> needs to understand the Mangling scheme as well.
> ClassName does some of this
> work now, finding out what the 'real' name of the
> class is.
> 
> Perhaps a Kit pattern is in order?
> 

Ah yes, the venerable ToolKit!

This is basically what I'm going for, with two tiers:

- a static, default layer of factory methods that is
independent of the runtime adaptor scheme.  This is
done via factories in a subclass of Constants.  This
layer has default behavior that is configurable via
standard configuration properties (both via -D and via
resource file).

- a run-time layer of factory methods that overrides
the default layer based on run-time options such as
init-params.  This is to be implemented in a subclass
of Options.

This pattern allows each adapter (i.e. JspC,
JspInterceptor) to adopt just the shared behavior that
is necessary by extending/re-implementing it's own
'options'-layer factories.

I must admit to not being totally sure whether
co-opting the current 'Constants' and 'Options' class
families is the best naming for this, but they do
clearly indicate the difference in scope.  I could
break the factory methods out into separate, new
'ConstantsToolkit' and 'OptionsToolkit'
class/interface types, but since they would parallel
the original, I don't see the real advantage.

> Refactoring Mangler is highly desireable from my day
> job point of view, too,
> since the current mangling scheme can cause problems
> on Windows. Although we
> might be able to move to Linux for developers
> desktops soon. 
> 

I ran into that some time back (mangling issues) and
was one of my motivations for doing this refactoring
earlier in my day-job implementation of JspServlet
(tc3.3).  The result of that effort works very well
and I'm borrowing heavily from it for this effort, but
this time I'm trying to put more support for (and
steal ideas from) other adapter options.

> to be thorough, I took our worst behaved JSP page,
> which happens to be our
> home page, and benchmarked it under several engines.
> TC33 blew the doors off
> the competition, up to levels of 177 concurrent
> connections, at which point
> the benchmark tool starting melting down.] 
> 

That is always good stuff to hear!  Costin deserves a
lot of the credit here, since that performance gain is
primarily (probably) coming from his JspInterceptor
implementation.  I know we can never get JspServlet to
be completely as fast, but we should be able to get it
much closer than it currently is.

 > 
> > But in any case, should be independent of
> everything 
> > else - just a component that may be used by the 
> > "container adapter" classes.
> > 
> > Costin
> 
> DIP, the dependencies should be on interfaces, not
> on classes.
> 

90% of the time I agree.  Some abstractions require
base or abstract classes, though, if part of the
specification fixes actual behavior.  This is often
the case when initialization must follow a fixed
pattern (i.e. a certain type of constructor signature
or other life-cycle methods must be supported).

This can sometimes be avoided if the interface is
well-thought out.  For example, the problem with the
current Mangler interface is that it does not support
any way to input the core parameters (the jsp URI and
the scratchdir) from which it's method must derive
their data.  In other words, we want a factory method
that works like so:

publc static Mangler createMangler(
String uri,String dir){..}

but we need a predictable way to communicate the
params to the created instance.  There are three ways
to fix this in order to support abstract creation
through factory methods.

1) rewrite the Mangler interface to have an
init(String,String) method or 'setJspUri(String)' and
'setOutputDir(String)' methods - this would be
optimal, but would break existing implementations of
Mangler.

2) create a default basic or abstract implementation
of Mangler (call it 'JspMangler' or whatever) and give
it a public constructor that takes the params.  The
factory method then becomes:

public static JspMangler createJspMangler(
  String, String){...}

The problem with this one is that it forces all new
Mangler implementations to subclass JspMangler.  This
is not necessarily a bad thing.

3) create a new interface ca

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[cmanolache]

On Fri, 30 Mar 2001, Mel Martinez wrote:

> --- Steve Downey <[EMAIL PROTECTED]> wrote:
>
> I must admit to not being totally sure whether
> co-opting the current 'Constants' and 'Options' class
> families is the best naming for this, but they do
> clearly indicate the difference in scope.  I could

My preference would be to completely drop the Constants,
and keep each "constant" in the class where it belongs
( but this is personal taste ).

One big issue is that we should avoid over-engineering this.
We need to improve jasper and do a refactoring - as a number 
of small code moves and interface changes. Then we can
evaluate the result and maybe repeat it. 

The goal is to simplify and modularize, and IMHO the only 
way that can be done right is via incremental steps, not a
"whaterfall" model ( and I don't want to start another
evolution/revolution, XP/waterfall flame war here :-). 

I would sugest to move to a vote, create the proposal/jasper34,
do a first step ( like the JspServlet changes you want, or 
the new packages - but with minimal interface changes ), evaluate
the result and maybe do another iteration. 

Mel, please don't try to resolve all the problems in one step 
or as a "block" design ( or a "perfect" initial design )  

> That is always good stuff to hear!  Costin deserves a
> lot of the credit here, since that performance gain is
> primarily (probably) coming from his JspInterceptor
> implementation.  I know we can never get JspServlet to

Thanks - but I haven't started yet :-)

Jsp "real" performance tunning can start only after refactoring. The goal
of 3.3 was to make the code simple and modular enough so we can _start_
optimizing it.


Costin

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[Mel Martinez]

--- [EMAIL PROTECTED] wrote:
> On Fri, 30 Mar 2001, Mel Martinez wrote:
> 
> > --- Steve Downey <[EMAIL PROTECTED]>
> wrote:
> >
> > I must admit to not being totally sure whether
> > co-opting the current 'Constants' and 'Options'
> class
> > families is the best naming for this, but they do
> > clearly indicate the difference in scope.  I could
> 
> My preference would be to completely drop the
> Constants,
> and keep each "constant" in the class where it
> belongs
> ( but this is personal taste ).
> 

Yeah, I agree.  I just didn't know if I wanted to go
through the pain of chopping these up too much just
yet.  After thinking about it though, I think instead
of extending these I will create separate classes for
the toolkit factory roles.  How about the names:

org.apache.jasper34.DefaultToolkit  (a class)

org.apache.jasper34.RuntimeToolkit (an interface)

A given adapter implementation would provide it's own
RuntimeToolkit implementation.  I think by making
these separate from the current Constants and Options
classes I've just simplified a bunch of things -
namely the ability to later on attack those two
classes.

> One big issue is that we should avoid
> over-engineering this.
> We need to improve jasper and do a refactoring - as
> a number 
> of small code moves and interface changes. Then we
> can
> evaluate the result and maybe repeat it. 
> 

Don't worry, most of the difficulty I'm having is over
the names to use in the proposal.  Yes, they will be
subject to change after that, but you know how they
tend to stick...


> 
> I would sugest to move to a vote, create the
> proposal/jasper34,
> do a first step ( like the JspServlet changes you
> want, or 
> the new packages - but with minimal interface
> changes ), evaluate
> the result and maybe do another iteration. 
> 
> Mel, please don't try to resolve all the problems in
> one step 
> or as a "block" design ( or a "perfect" initial
> design )  

Don't worry, this is going to be a very focused first
step that, like I said, focuses mainly on JspServlet. 
I've got the advantage of being able to leverage
something I already built.  The only major thing I'm
changing is to try to break my existing factory model
into something more flexible for future refactoring of
other parts of Jasper by using the two tiers
described.

I don't have the time to do much more than that!  That
Damn Day Job(tm) keeps getting in the way!  :-)

Mel

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/?.refer=text

RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet

[cmanolache]

On Fri, 30 Mar 2001, Mel Martinez wrote:

> I don't have the time to do much more than that!  That
> Damn Day Job(tm) keeps getting in the way!  :-)


Yea, believe me, I know what you mean, you're not the only one :-)

Costin

Re: More naming woes...

[Craig R. McClanahan]

On Thu, 29 Mar 2001, T. Park wrote:

> Remy,
> 
> thanks, that's good to hear - I'm still having a nightmare of a time resolving
> one last issue.
> 
> I have a large jar file that contains, amongst other things (e.g. an ejb
> container, a namingservice etc) javax.naming package.
> 

Are you including the javax.naming.* API classes (from JNDI) yourself?  If
so, this seems like a bad idea because they will already be in the JDK's
core classes (on a JDK 1.3 platform) or added to Tomcat's common
classloader (on a JDK 1.2 platform).  Doing this sounds like asking for
conflicts.

> If I deploy this to the common/lib and start tomcat I get the following
> exception however,
> if I remove the javax.naming package from my jarfile the issue goes
away (but
> burns me in a different situation
> later):
> 
> I'm hoping that when the naming references are placed in a jar file separate
> from StandardContext, this very strange problem
> may clear up - out of interest - any one have any idea what the error means?
> (After all - the method createNamingContext isn't actually
> being called (or at least it shouldn't be!)
> 
> -Thom
> 
> Here's the exception:
> 
> Exception during startup processing
> java.lang.reflect.InvocationTargetException: java.lang.VerifyError: (class:
> org/
> apache/catalina/core/StandardContext, method: createNamingContext signature:
> ()V
> ) Incompatible argument to function

Normally, this kind of error would mean you've compiled against one
version of the createNamingContext() method signature, and then
StandardContext was changed but the calling code was not recompiled.  Hmm,
that seems hard to do when createNamingContext() is a private method ...

> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:120)
> at org.apache.catalina.util.xml.ObjectCreate.start(XmlMapper.java:611)
> at
> org.apache.catalina.util.xml.XmlMapper.matchStart(XmlMapper.java:412)
> 
> at
> org.apache.catalina.util.xml.XmlMapper.startElement(XmlMapper.java:91
> )
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1391)
> at com.sun.xml.parser.Parser.content(Parser.java:1499)
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> at com.sun.xml.parser.Parser.content(Parser.java:1499)
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> at com.sun.xml.parser.Parser.content(Parser.java:1499)
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> at com.sun.xml.parser.Parser.content(Parser.java:1499)
> at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
> at com.sun.xml.parser.Parser.parse(Parser.java:284)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:155)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:126)
> at org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:228)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:657)

This is where the server.xml file is being read.  The next challenge is to
figure out what line number being processed when the error occurs.  You
can get more copious output by adding "-debug" to the startup command
line.

> at org.apache.catalina.startup.Catalina.execute(Catalina.java:627)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:177)
> at java.lang.reflect.Method.invoke(Native Method)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:177)
> 

Craig

> Remy Maucherat wrote:
> 
> > > Hi Folks,
> > >
> > > I'm [still] trying to get an alternative naming service plugged into
> > > Tomcat 4.
> > >
> > > I managed to hack together a working environment but, unfortunately, it
> > > wouldn't cut it long-term.
> > >
> > > I've discovered that if I run with naming disabled (catalina run
> > > -nonaming) it seems
> > > that tomcat still goes looking for apache naming stuff.
> > >
> > > I discovered this when I moved the naming.jar out of common/lib and got
> > > the following exception which suggests to me
> > > that naming isn't going to be replaced willingly ;-)
> > >
> > > Any suggestions how I go about plugging in an alternative naming
> > > service?
> >
> > The dir contexts are *also* part of naming.jar, so naming.jar has to be
> > there if you want Catalina to run.
> >
> > Although Standard context has actual dependencies on
> > org.apache.naming.xxxRef objects and others, I promise that if you're using
> > "-nonaming" none of these will actually get initialized or used. I can sign
> > a paper if you want ;)
> > It's safe to say that we'll move the naming initialization to a separate
> > class (but that will happen after b2).
> >
> > Remy
> 
> --
> http://www.borland.com/newsgroups
> http://www.borland.com/devsupport/disclaim.html
> 
> 
> 

Re: [PATCH] build.xml instead of build.sh

[Craig R. McClanahan]

On Fri, 30 Mar 2001, Matthew L Daniel wrote:

> I (personally) hate setting all those crazy environmental variables to build
> Catalina, and since Ant is kind enough to ignore the "property file" tag if
> the file does not exist, I feel this can be safely included for general use.
> 

I've had positive success with eliminating build.sh and build.bat (and the
associated environment variables) entirely on other projects, in favor of
using Ant properties files.  I will be happy to see us do this on Tomcat
4 a well -- but please, not until after beta 2 :-).

>   -- /v\atthew
> -- 

Craig

> Matthew L DanielNever put off until tomorrow what you can do today.
> Wizard  There might be a law against it by that time.
> [EMAIL PROTECTED]-- `/usr/bin/fortune`
> 

Re: SendMailFactory.java breaks compile

[Craig R. McClanahan]

On Fri, 30 Mar 2001, Stuart Roebuck wrote:

> I've just tried to compile the latest CVS of Tomcat 4 and I'm missing some 
> classes trying to compile SendMailFactory.java.
> 
> /Users/stuart/OpenSource/jakarta-tomcat-4.0/catalina/src/share/org/apache/
> naming/factory/SendMailFactory.java:0: Class javax.activation.DataSource 
> not found in class javax.mail.internet.MimePartDataSource.
> 
> I tried dropping Java Mail 1.2 into the classpath but this doesn't help.
> 

You need the Java Activation Framework (JAF) as well.  If it's not in the
README, I will update that ASAP.

> Am I missing something obvious?
> 
> Stuart.
> 
Craig


> -
> Stuart Roebuck  [EMAIL PROTECTED]
> Lead Developer   Java, XML, MacOS X, XP, etc.
> ADOLOS http://www.adolos.com/
> 

Tomcat and IPv6

[Ibrahim Haddad (LMC)]

Hello,

I am working on IPv6 at Ericsson Research Canada. I would like
to check if Tomcat has support for IPv6 addressing format.
I would really appreciate your feedback.

Thank you.

--
Ibrahim Haddad 
Open Architecture Research Lab 

RE: Running Tomcat without tools.jar (javac) after precompiling my jsp's.

[Szegedi, Attila]

You should run jspc with -webinc switch. It will generate an XML fragment
that you should add to your web.xml file (either by copy/paste or by
including it as an entity); It will look like this:


com.mycompany.foo.myjsppage
com.mycompany.foo.myjsppage


/com/mycompany/foo/myjsppage.jsp
hu.scriptum.rolemgr.addrole


If you don't like the default URL patterns, change them to what you like. I
invoke jspc through Ant, so a  task after jspc-invoking  task
does the job.

One thing to watch for is that the compiled classes depend on the
org.apache.jasper.runtime package, so your webapp will either be tied to
Tomcat, or you should distribute org.apache.jasper.runtime package (found in
jasper.jar) with your webapp.

Also please note that questions regarding Tomcat usage should go to
tomcat-user list instead.

Attila.

tomcat 4.0 b1/apache 1.3.12: trouble with sessions

[a . wille]

Hi,

I'm just evaluating tomcat 4.0 b1 and apache 1.3.12 on a solaris 2.6 system.
After installing tomcat (as stand-alone) and successfully testing the examples, I tried to connect tomcat and apache using mod_webapp. This works also fine. But testing the session servlet example fails. It seems that neither cookies nor url-encoding works with mod_webapp. 
Is that true or just a misconfiguration?

Thanks,
Andreas

FW: Tomcat may reveal script source code by URL trickery

[Renzo Toma]

Just in case you missed it.

-Original Message-
From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of Sverre
H. Huseby
Sent: donderdag 29 maart 2001 10:12
To: [EMAIL PROTECTED]
Subject: Tomcat may reveal script source code by URL trickery


Tomcat may reveal script source code by URL trickery


Sverre H. Huseby advisory 2001-03-29



Systems affected


Tomcat 4.0-b1 (latest milestone) and nighly build as of 2001-03-28
tested.  Other versions may be vulnerable too.  The problem is only
present when using Tomcat's built in web server, not when using Tomcat
with Apache Web Server.


Description
---

Tomcat (http://jakarta.apache.org/tomcat/), the Reference
Implementation for the Java Servlet 2.2 and JavaServer Pages 1.1
Technologies, may be tricked into revealing the source code of JSP
scripts by using simple URL encoding.


Details
---

It seems that the built in web server in Tomcat does URL decoding in
an unreasonable order.  URLs like the following

  http://XXX:8080/examples/jsp/num/numguess.js%70

where %70 is an URL encoded 'p', returns the source code of index.jsp
rather than running the script on the server side.

To speculate: The JSP handler is skipped as this URL does not end in
".jsp", but the static file handler is nevertheless able to map the
URL into a correct file name.


Impact
--

This design error makes it possible to fetch the source code of JSP
scripts.  Such source code may contain database passwords and file
names, and may reveal design errors or programming bugs that make it
possible to further exploit the server or service.



Reported by Sverre H. Huseby, [EMAIL PROTECTED]

--
mailto:[EMAIL PROTECTED]>
http://shh.thathost.com/>

Tomcat Feedback

[Ben Hutchison]

Hi Tomcat Developers,
 
I work at Finetix London, a technical consultancy 
working with a lot of J2EE and XML/XSL technology. Over the last weeks, my 
colleage and I have been using Tomcat 3.2.1 for JSP/Servlet development, and we 
encountered a couple of glitches/issues which I describe below.
 
 
1. When using Xalan 2 with Tomcat, the default 
classpath shadows some Xalan 2 classes with classes in jaxp.jar and parser.jar, 
so that Xalan fails to work. Editing of tomcat.bat is required to fix the 
problem by moving Xalan.jar forward.
 
 
2. Inheritance of MIME mappings from the base web.xml to web apps did not 
seem to work, although the docs specified this behavior. Eg: We set up a 
mapping for .WML files in the base web.xml, restarted, but WML files were served 
as plain text. The same mapping in the web apps /WEB_INF/web.xml file did effect 
the mapping.
 
 
3. Exception messages of type org.apache.jasper.compiler.ParseException 
(eg: "C:\software\tomcat\webapps\test\MyTest.jsp(20,4) Invalid directive") are 
often quite uninformative. They dont supply details about the expression that 
caused the problem, nor why that expression was "bad" or "invalid". This makes 
development more difficult. Also these exceptions dont seem to be logged. 

 
4. . When using Xalan 2.0.1 with Tomcat 3.2.1, the default config shadows 
some Xalan 2 classes with classes in jaxp.jar and parser.jar, so that Xalan 
fails to work. Editing of tomcat.bat is required to fix the problem by moving 
Xalan.jar forward. Since Xalan and Tomcat are both from Apache projects, both 
recent production versions, and are very likely to be used together, I think 
they should co-exist well out-of-the-box.
 
 
5. The resolution of filename URLs within JSP Pages seemed a frequent 
source of trouble, (Eg <%@ include file="relative url">). 
    a) We found it very difficult to determine exactly what 
URL format tomcat undertstands. It didnt seem to be standard and it didnt seem 
to be documented.
    b) It frequently throws exceptions for relative URLs of 
the form "../X" or "./" where it reports a bad file argument, but doesnt print 
either the file argument that thinks is bad, nor the reason why.
    c) We were unable to find a url form that allowed us to 
specify paths to other drive letters under Windows.
 
 
6. There seems to be little or no description in the docs of how to put 
pages into the server root dir. The docs focus on web-app context-linked 
sub-directories. Could this be described more prominently?
 
 
7. (Minor) The /test index.html would be more useful with hyperlinks the 
actual test pages below it.
 
Regards
Ben

Re: More naming woes...

[T. Park]

Hi Craig,

I agree with you - bundling the javax.naming... is a bit of a problem waiting to
happen.

The original reason was as a 'convenience'  for end-users that weren't on JDK 1.3,
as it was the
same classes from JSEE 1.2.1 there wasn't a conflict.

Of course who knows what the future will bring ;-)

I haven't changed StandardContext - though I have munged ContextConfig though -
could this be part of the
problem? ContextConfig now will refer to some classes that are based on 'my stuff'
which do, ultimately
call some javax.naming.

I still can't explain that odd error -what argument and what function?

-Thom



"Craig R. McClanahan" wrote:

> On Thu, 29 Mar 2001, T. Park wrote:
>
> > Remy,
> >
> > thanks, that's good to hear - I'm still having a nightmare of a time resolving
> > one last issue.
> >
> > I have a large jar file that contains, amongst other things (e.g. an ejb
> > container, a namingservice etc) javax.naming package.
> >
>
> Are you including the javax.naming.* API classes (from JNDI) yourself?  If
> so, this seems like a bad idea because they will already be in the JDK's
> core classes (on a JDK 1.3 platform) or added to Tomcat's common
> classloader (on a JDK 1.2 platform).  Doing this sounds like asking for
> conflicts.
>
> > If I deploy this to the common/lib and start tomcat I get the following
> > exception however,
> > if I remove the javax.naming package from my jarfile the issue goes
> away (but
> > burns me in a different situation
> > later):
> >
> > I'm hoping that when the naming references are placed in a jar file separate
> > from StandardContext, this very strange problem
> > may clear up - out of interest - any one have any idea what the error means?
> > (After all - the method createNamingContext isn't actually
> > being called (or at least it shouldn't be!)
> >
> > -Thom
> >
> > Here's the exception:
> >
> > Exception during startup processing
> > java.lang.reflect.InvocationTargetException: java.lang.VerifyError: (class:
> > org/
> > apache/catalina/core/StandardContext, method: createNamingContext signature:
> > ()V
> > ) Incompatible argument to function
>
> Normally, this kind of error would mean you've compiled against one
> version of the createNamingContext() method signature, and then
> StandardContext was changed but the calling code was not recompiled.  Hmm,
> that seems hard to do when createNamingContext() is a private method ...
>
> > at java.lang.Class.forName0(Native Method)
> > at java.lang.Class.forName(Class.java:120)
> > at org.apache.catalina.util.xml.ObjectCreate.start(XmlMapper.java:611)
> > at
> > org.apache.catalina.util.xml.XmlMapper.matchStart(XmlMapper.java:412)
> >
> > at
> > org.apache.catalina.util.xml.XmlMapper.startElement(XmlMapper.java:91
> > )
> > at com.sun.xml.parser.Parser.maybeElement(Parser.java:1391)
> > at com.sun.xml.parser.Parser.content(Parser.java:1499)
> > at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> > at com.sun.xml.parser.Parser.content(Parser.java:1499)
> > at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> > at com.sun.xml.parser.Parser.content(Parser.java:1499)
> > at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> > at com.sun.xml.parser.Parser.content(Parser.java:1499)
> > at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
> > at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
> > at com.sun.xml.parser.Parser.parse(Parser.java:284)
> > at javax.xml.parsers.SAXParser.parse(SAXParser.java:155)
> > at javax.xml.parsers.SAXParser.parse(SAXParser.java:126)
> > at org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:228)
> > at org.apache.catalina.startup.Catalina.start(Catalina.java:657)
>
> This is where the server.xml file is being read.  The next challenge is to
> figure out what line number being processed when the error occurs.  You
> can get more copious output by adding "-debug" to the startup command
> line.
>
> > at org.apache.catalina.startup.Catalina.execute(Catalina.java:627)
> > at org.apache.catalina.startup.Catalina.process(Catalina.java:177)
> > at java.lang.reflect.Method.invoke(Native Method)
> > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:177)
> >
>
> Craig
>
> > Remy Maucherat wrote:
> >
> > > > Hi Folks,
> > > >
> > > > I'm [still] trying to get an alternative naming service plugged into
> > > > Tomcat 4.
> > > >
> > > > I managed to hack together a working environment but, unfortunately, it
> > > > wouldn't cut it long-term.
> > > >
> > > > I've discovered that if I run with naming disabled (catalina run
> > > > -nonaming) it seems
> > > > that tomcat still goes looking for apache naming stuff.
> > > >
> > > > I discovered this when I moved the naming.jar out of common/lib and got
> > > > the following exception which suggests to m

Re: FW: Tomcat may reveal script source code by URL trickery

[Craig R. McClanahan]

On Fri, 30 Mar 2001, Renzo Toma wrote:

> 
> Just in case you missed it.
> 

I'm working on this ... (compiling as I type).

Craig


> -Original Message-
> From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of Sverre
> H. Huseby
> Sent: donderdag 29 maart 2001 10:12
> To: [EMAIL PROTECTED]
> Subject: Tomcat may reveal script source code by URL trickery
> 
> 
> Tomcat may reveal script source code by URL trickery
> 
> 
> Sverre H. Huseby advisory 2001-03-29
> 
> 
> 
> Systems affected
> 
> 
> Tomcat 4.0-b1 (latest milestone) and nighly build as of 2001-03-28
> tested.  Other versions may be vulnerable too.  The problem is only
> present when using Tomcat's built in web server, not when using Tomcat
> with Apache Web Server.
> 
> 
> Description
> ---
> 
> Tomcat (http://jakarta.apache.org/tomcat/), the Reference
> Implementation for the Java Servlet 2.2 and JavaServer Pages 1.1
> Technologies, may be tricked into revealing the source code of JSP
> scripts by using simple URL encoding.
> 
> 
> Details
> ---
> 
> It seems that the built in web server in Tomcat does URL decoding in
> an unreasonable order.  URLs like the following
> 
>   http://XXX:8080/examples/jsp/num/numguess.js%70
> 
> where %70 is an URL encoded 'p', returns the source code of index.jsp
> rather than running the script on the server side.
> 
> To speculate: The JSP handler is skipped as this URL does not end in
> ".jsp", but the static file handler is nevertheless able to map the
> URL into a correct file name.
> 
> 
> Impact
> --
> 
> This design error makes it possible to fetch the source code of JSP
> scripts.  Such source code may contain database passwords and file
> names, and may reveal design errors or programming bugs that make it
> possible to further exploit the server or service.
> 
> 
> 
> Reported by Sverre H. Huseby, [EMAIL PROTECTED]
> 
> --
> mailto:[EMAIL PROTECTED]>
> http://shh.thathost.com/>
> 
> 

RE: FW: Tomcat may reveal script source code by URL trickery

[Marc Saegesser]

Tomcat 3.1.x and 3.2.x do not suffer from this problem.

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 30, 2001 12:26 PM
> To: [EMAIL PROTECTED]
> Subject: Re: FW: Tomcat may reveal script source code by URL trickery
>
>
>
>
> On Fri, 30 Mar 2001, Renzo Toma wrote:
>
> >
> > Just in case you missed it.
> >
>
> I'm working on this ... (compiling as I type).
>
> Craig
>
>
> > -Original Message-
> > From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of Sverre
> > H. Huseby
> > Sent: donderdag 29 maart 2001 10:12
> > To: [EMAIL PROTECTED]
> > Subject: Tomcat may reveal script source code by URL trickery
> >
> >
> > Tomcat may reveal script source code by URL trickery
> > 
> >
> > Sverre H. Huseby advisory 2001-03-29
> >
> >
> >
> > Systems affected
> > 
> >
> > Tomcat 4.0-b1 (latest milestone) and nighly build as of 2001-03-28
> > tested.  Other versions may be vulnerable too.  The problem is only
> > present when using Tomcat's built in web server, not when using Tomcat
> > with Apache Web Server.
> >
> >
> > Description
> > ---
> >
> > Tomcat (http://jakarta.apache.org/tomcat/), the Reference
> > Implementation for the Java Servlet 2.2 and JavaServer Pages 1.1
> > Technologies, may be tricked into revealing the source code of JSP
> > scripts by using simple URL encoding.
> >
> >
> > Details
> > ---
> >
> > It seems that the built in web server in Tomcat does URL decoding in
> > an unreasonable order.  URLs like the following
> >
> >   http://XXX:8080/examples/jsp/num/numguess.js%70
> >
> > where %70 is an URL encoded 'p', returns the source code of index.jsp
> > rather than running the script on the server side.
> >
> > To speculate: The JSP handler is skipped as this URL does not end in
> > ".jsp", but the static file handler is nevertheless able to map the
> > URL into a correct file name.
> >
> >
> > Impact
> > --
> >
> > This design error makes it possible to fetch the source code of JSP
> > scripts.  Such source code may contain database passwords and file
> > names, and may reveal design errors or programming bugs that make it
> > possible to further exploit the server or service.
> >
> >
> >
> > Reported by Sverre H. Huseby, [EMAIL PROTECTED]
> >
> > --
> > mailto:[EMAIL PROTECTED]>
> > http://shh.thathost.com/>
> >
> >

Stress Test problems with 3.2.1

[tomcat-dev-list]

Hello,
I have tc 3.2.1 installed on w2k server with iis5, sun hotspot 2.0 server
mode and jdk 1.3.  I have been running this implementation successfully for
the past several months with no problems.  I decided to perform a stress
test to see how tc would handle it.

1. First test. 100 concurrent connections, each submitting a request to
/examples/jsp/forward.jsp every 10 seconds.  This equated to 11 requests per
second.  I ran this test for 24 hours.  Results were perfect, no errors.

2. Second test.  same test as above with 200 concurrent connections.  This
equated to 18 requests per second.  Ran for 5 minutes.  This time I received
errors on 1% of the requests -- "500 - Internal Server Error".  I checked
the Tomcat log and I am getting NullPointerExceptions from the jsp code
followed by an ArrayIndexOutOfBoundsException at
tomcat.util.SimplePool.put(SimplePool.java:112).  The redirect dll reports a
few problems of not being able to handle the tc response.  I suspect tc
could not deliver a response because of the internal errors.  Not sure.

I go back to test 1 and everything is back to perfect.  Go to test 2 again
and same errors.  As I lowered the number of requests per second, it gets
better.  It did not matter if I had 300 concurrent connections as long as
the request per second was around 11, everything worked fine.  Does anyone
know what's up here?

Thanks
Mike
[EMAIL PROTECTED]

RE: Tomcat Feedback

[Marc Saegesser]

Ben,

Thanks for your feedback.  I'll try to respond to your issues below.  Also,
if at all possible, try using the Tomcat 3.2.2b2 release to see if it
addresses any of your concerns.

1.  Classes loaded by the container take precedence over classes from Jar
files in WEB-INF/lib.  In tomcat 3.x there really isn't anything we can do
about this.  The Servlet 2.3 (Proposed Final Draft) specification allows
containers to let classes inside the web application override those from the
container (section 9.6.2).  Tomcat 4.0 implements this specification and
does support this feature.

2.  The system wide web.xml is no longer supported in Tomcat 3.2.x because
it was a non-standard extension to the Servlet specification.  All web
application configuration is now do in WEB-INF/web.xml files within the
webapps.

3.  Agreed.  I think there are already some Bugzilla bug reports on this
topic.

4.  I think this is related to the same issue as item 1.

5.  The treatment of relative URLs is addresssed in section 2.5.2 of the JSP
1.1 specification and Tomcat 3.2.x does implement this correctly.  A URL
like "fubar.jsp" is a 'page relative' URL and will be resolved relative the
current JSP page.  A URL like "/fubar.jsp" is a 'context relative' URL and
will be interpreted rooted at the base of the web application.  There is no
mechanism to include resourses outside the web application.  A relative URL
that tries to use several ../../.. to 'escape' from the web application will
fail.

6.  The documentation can certainly be made better.  Voluteers are always
welcome!

7.  Same as above!


-Original Message-
From: Ben Hutchison [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 30, 2001 9:00 AM
To: [EMAIL PROTECTED]
Subject: Tomcat Feedback


Hi Tomcat Developers,

I work at Finetix London, a technical consultancy working with a lot of J2EE
and XML/XSL technology. Over the last weeks, my colleage and I have been
using Tomcat 3.2.1 for JSP/Servlet development, and we encountered a couple
of glitches/issues which I describe below.


1. When using Xalan 2 with Tomcat, the default classpath shadows some Xalan
2 classes with classes in jaxp.jar and parser.jar, so that Xalan fails to
work. Editing of tomcat.bat is required to fix the problem by moving
Xalan.jar forward.


2. Inheritance of MIME mappings from the base web.xml to web apps did not
seem to work, although the docs specified this behavior. Eg: We set up a
mapping for .WML files in the base web.xml, restarted, but WML files were
served as plain text. The same mapping in the web apps /WEB_INF/web.xml file
did effect the mapping.


3. Exception messages of type org.apache.jasper.compiler.ParseException (eg:
"C:\software\tomcat\webapps\test\MyTest.jsp(20,4) Invalid directive") are
often quite uninformative. They dont supply details about the expression
that caused the problem, nor why that expression was "bad" or "invalid".
This makes development more difficult. Also these exceptions dont seem to be
logged.


4. . When using Xalan 2.0.1 with Tomcat 3.2.1, the default config shadows
some Xalan 2 classes with classes in jaxp.jar and parser.jar, so that Xalan
fails to work. Editing of tomcat.bat is required to fix the problem by
moving Xalan.jar forward. Since Xalan and Tomcat are both from Apache
projects, both recent production versions, and are very likely to be used
together, I think they should co-exist well out-of-the-box.


5. The resolution of filename URLs within JSP Pages seemed a frequent source
of trouble, (Eg <%@ include file="relative url">).
a) We found it very difficult to determine exactly what URL format
tomcat undertstands. It didnt seem to be standard and it didnt seem to be
documented.
b) It frequently throws exceptions for relative URLs of the form "../X"
or "./" where it reports a bad file argument, but doesnt print either the
file argument that thinks is bad, nor the reason why.
c) We were unable to find a url form that allowed us to specify paths to
other drive letters under Windows.


6. There seems to be little or no description in the docs of how to put
pages into the server root dir. The docs focus on web-app context-linked
sub-directories. Could this be described more prominently?


7. (Minor) The /test index.html would be more useful with hyperlinks the
actual test pages below it.

Regards
Ben

RE: Stress Test problems with 3.2.1

[Marc Saegesser]

Could you please try this test with Tomcat 3.2.2 beta 2?  I believe this
problem has been fixed in this release.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 30, 2001 1:08 PM
> To: [EMAIL PROTECTED]
> Subject: Stress Test problems with 3.2.1
>
>
> Hello,
> I have tc 3.2.1 installed on w2k server with iis5, sun hotspot 2.0 server
> mode and jdk 1.3.  I have been running this implementation
> successfully for
> the past several months with no problems.  I decided to perform a stress
> test to see how tc would handle it.
>
> 1. First test. 100 concurrent connections, each submitting a request to
> /examples/jsp/forward.jsp every 10 seconds.  This equated to 11
> requests per
> second.  I ran this test for 24 hours.  Results were perfect, no errors.
>
> 2. Second test.  same test as above with 200 concurrent connections.  This
> equated to 18 requests per second.  Ran for 5 minutes.  This time
> I received
> errors on 1% of the requests -- "500 - Internal Server Error".  I checked
> the Tomcat log and I am getting NullPointerExceptions from the jsp code
> followed by an ArrayIndexOutOfBoundsException at
> tomcat.util.SimplePool.put(SimplePool.java:112).  The redirect
> dll reports a
> few problems of not being able to handle the tc response.  I suspect tc
> could not deliver a response because of the internal errors.  Not sure.
>
> I go back to test 1 and everything is back to perfect.  Go to test 2 again
> and same errors.  As I lowered the number of requests per second, it gets
> better.  It did not matter if I had 300 concurrent connections as long as
> the request per second was around 11, everything worked fine.  Does anyone
> know what's up here?
>
> Thanks
> Mike
> [EMAIL PROTECTED]
>

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util RequestUtil.java

[craigmcc]

craigmcc01/03/30 11:33:39

  Modified:catalina/src/share/org/apache/catalina/core
LocalStrings.properties StandardContextMapper.java
StandardContextValve.java StandardWrapperValve.java
   catalina/src/share/org/apache/catalina/util RequestUtil.java
  Log:
  Fix for the "Tomcat may reveal script source code by URL trickery"
  security vulnerability reported by Sverre H. Huseby (2001-03-29).  The
  problem was that we were not URL decoding the servletPath and pathInfo
  parts of a request URI at all (which is a spec violation as well).
  
  In addition, fixed one more case where the cross-site scripting
  vulnerability problem reported earlier could have bitten us.
  
  Revision  ChangesPath
  1.26  +182 -180  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/LocalStrings.properties,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- LocalStrings.properties   2001/03/26 03:22:35 1.25
  +++ LocalStrings.properties   2001/03/30 19:33:37 1.26
  @@ -1,180 +1,182 @@
  -applicationContext.attributeEvent=Exception thrown by attributes event listener
  -applicationContext.requestDispatcher.iae=Path {0} does not start with a "/" 
character
  -applicationDispatcher.allocateException=Allocate exception for servlet {0}
  -applicationDispatcher.deallocateException=Deallocate exception for servlet {0}
  -applicationDispatcher.forward.ise=Cannot forward after response has been committed
  -applicationDispatcher.forward.throw=Forwarded resource threw an exception
  -applicationDispatcher.include.throw=Included resource threw an exception
  -applicationDispatcher.isUnavailable=Servlet {0} is currently unavailable
  -applicationDispatcher.serviceException=Servlet.service() for servlet {0} threw 
exception
  -applicationRequest.badParent=Cannot locate parent Request implementation
  -applicationRequest.badRequest=Request is not a javax.servlet.ServletRequestWrapper
  -applicationResponse.badParent=Cannot locate parent Response implementation
  -applicationResponse.badResponse=Response is not a 
javax.servlet.ServletResponseWrapper
  -containerBase.addDefaultMapper=Exception configuring default mapper of class {0}
  -containerBase.alreadyStarted=Container has already been started
  -containerBase.notConfigured=No basic Valve has been configured
  -containerBase.notStarted=Container has not been started
  -filterChain.filter=Filter execution threw an exception
  -filterChain.servlet=Servlet execution threw an exception
  -httpContextMapper.container=This container is not a StandardContext
  -httpEngineMapper.container=This container is not a StandardEngine
  -httpHostMapper.container=This container is not a StandardHost
  -interceptorValve.alreadyStarted=InterceptorValve has already been started
  -interceptorValve.notStarted=InterceptorValve has not yet been started
  -standardContext.alreadyStarted=Context has already been started
  -standardContext.applicationListener=Error configuring application listener of class 
{0}
  -standardContext.applicationSkipped=Skipped installing application listeners due to 
previous error(s)
  -standardContext.errorPage.error=Error page location {0} must start with a '/'
  -standardContext.errorPage.required=ErrorPage cannot be null
  -standardContext.errorPage.warning=WARNING: Error page location {0} must start with 
a '/' in Servlet 2.3
  -standardContext.filterMap.either=Filter mapping must specify either a  
or a 
  -standardContext.filterMap.name=Filter mapping specifies an unknown filter name {0}
  -standardContext.filterMap.pattern=Invalid  {0} in filter mapping
  -standardContext.filterStart=Exception starting filter {0}
  -standardContext.isUnavailable=This application is not currently available
  -standardContext.listenerStart=Exception sending context initialized event to 
listener instance of class {0}
  -standardContext.listenerStop=Exception sending context destroyed event to listener 
instance of class {0}
  -standardContext.loginConfig.errorPage=Form error page {0} must start with a '/'
  -standardContext.loginConfig.errorWarning=WARNING: Form error page {0} must start 
with a '/' in Servlet 2.3
  -standardContext.loginConfig.loginPage=Form login page {0} must start with a '/'
  -standardContext.loginConfig.loginWarning=WARNING: Form login page {0} must start 
with a '/' in Servlet 2.3
  -standardContext.loginConfig.required=LoginConfig cannot be null
  -standardContext.managerLoad=Exception loading sessions from persistent storage
  -standardContext.managerUnload=Exception unloading sessions to persistent storage
  -standardContext.mappingError=MAPPING configuration error for relative URI {0}
  -standardContext.notFound=The requested r

[VOTE] Tomcat 4.0 Beta 2 Release Tonight (Fixed Security Vulnerability)

[Craig R. McClanahan]

I'd like to propose that we create and publish a Tomcat 4.0 beta 2 release
tonight, based on the current CVS code base.  The primary reason for the
expedited schedule is that this code will include a fix for the "Tomcat
may reveal script source code by URL trickery" security vulnerability, as
well as lots of other bug fixes.

Comments?  Votes?

Craig McClanahan

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util RequestUtil.java

[Remy Maucherat]

>   +relativeURI = URLDecoder.decode(relativeURI);

That doesn't decode using the right format. Maybe it works in that case, but
I suggest using RequestUtil.URLDecode instead.

Remy

Re: [VOTE] Tomcat 4.0 Beta 2 Release Tonight (Fixed Security Vulnerability)

[Remy Maucherat]

> I'd like to propose that we create and publish a Tomcat 4.0 beta 2 release
> tonight, based on the current CVS code base.  The primary reason for the
> expedited schedule is that this code will include a fix for the "Tomcat
> may reveal script source code by URL trickery" security vulnerability, as
> well as lots of other bug fixes.
> 
> Comments?  Votes?

+1.

Remy

RE: Tomcat Feedback

[cmanolache]

On Fri, 30 Mar 2001, Marc Saegesser wrote:

> 1.  Classes loaded by the container take precedence over classes from Jar
> files in WEB-INF/lib.  In tomcat 3.x there really isn't anything we can do
> about this.  The Servlet 2.3 (Proposed Final Draft) specification allows
> containers to let classes inside the web application override those from the
> container (section 9.6.2).  Tomcat 4.0 implements this specification and
> does support this feature.

Marc, a small correction here: tomcat 3.3 doesn't have this problem - the
container is loaded in a completely separated class loader ( that includes
jaxp, parser, modules, etc) - the webapplications and the container are
sharing only javax.servlet.* package and the core ( i.e. 6 classes + 10
utils - not even that is required and you can reconfigure that )

That means you shouln't have any problem with "sealing" or plugging a
different parser. 

The downside is that webapps no longer have a parser provided by default -
but that's easy to fix by including one in lib/apss ( not necesarily the
same used by the container ). 

With the (experimental) ProfileLoader you can have different jaxp parsers
or jars available to groups of applications.

Tomcat 3.3 doens't support the "overriding" feature - but it doesn't have
anything exposed that would need to be overriden - the apps get a clean
environment, unless configured in a different way - in which case the
configured jars do override the app jars. ( this is important for things
like JDBC drivers and sandboxing, since you'll grand permissions to the
container's jar - instead of granting them to the jar in the webapp that
can be corupted. 


Nacho can explain more about this, as he did most of the work.


Costin

( of course, the 3.3 loading also support the "multiple facades" feature -
but it needs some special configurations to run servlet23/servet22 at the 
same time )

Re: [VOTE] Tomcat 4.0 Beta 2 Release Tonight (Fixed Security Vulnerability)

[Amy Roh]

- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 30, 2001 11:36 AM
Subject: [VOTE] Tomcat 4.0 Beta 2 Release Tonight (Fixed Security
Vulnerability)


> I'd like to propose that we create and publish a Tomcat 4.0 beta 2 release
> tonight, based on the current CVS code base.  The primary reason for the
> expedited schedule is that this code will include a fix for the "Tomcat
> may reveal script source code by URL trickery" security vulnerability, as
> well as lots of other bug fixes.
>
> Comments?  Votes?
>
> Craig McClanahan
>
>

+1

Cheers,

Amy

Re: [VOTE] Tomcat 4.0 Beta 2 Release Tonight (Fixed SecurityVulnerability)

[Jon Stevens]

on 3/30/01 11:36 AM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:

> I'd like to propose that we create and publish a Tomcat 4.0 beta 2 release
> tonight, based on the current CVS code base.  The primary reason for the
> expedited schedule is that this code will include a fix for the "Tomcat
> may reveal script source code by URL trickery" security vulnerability, as
> well as lots of other bug fixes.
> 
> Comments?  Votes?
> 
> Craig McClanahan

+0

-jon

cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B2.txt

[craigmcc]

craigmcc01/03/30 12:31:53

  Modified:.RELEASE-NOTES-4.0-B2.txt
  Log:
  Update beta-2 release notes to reflect changes made to date.
  
  Need to verify behavior of several of the new features (running Jasper using
  Xerces 1.3, compression filter, and server-side includes) before including
  them in the beta 2 release.
  
  Revision  ChangesPath
  1.3   +87 -8 jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B2.txt
  
  Index: RELEASE-NOTES-4.0-B2.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B2.txt,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- RELEASE-NOTES-4.0-B2.txt  2001/03/24 01:23:21 1.2
  +++ RELEASE-NOTES-4.0-B2.txt  2001/03/30 20:31:52 1.3
  @@ -3,7 +3,7 @@
   Release Notes
   =
   
  -$Id: RELEASE-NOTES-4.0-B2.txt,v 1.2 2001/03/24 01:23:21 craigmcc Exp $
  +$Id: RELEASE-NOTES-4.0-B2.txt,v 1.3 2001/03/30 20:31:52 craigmcc Exp $
   
   
   
  @@ -24,6 +24,8 @@
   IMPORTANT SECURITY NOTE:  This release includes a fix to a "cross site
   scripting vulnerability" caused by a request URI such as:
 http://localhost:8080/alert(document.cookie).xyz
  +and the "may expose JSP source code" vulnerability caused by:
  +  http://localhost:8080/examples/jsp/snp/snoop.js%70
   
   
   
  @@ -61,7 +63,12 @@
   approved by the JSR-053 Expert Group, and will appear in the next release
   of the specification.
   
  +Resource Factory for javax.mail.Session Objects:  You can now use the
  + element in a web.xml file (and the corresponding resource
  +configuration in server.xml) to create javax.mail.Session objects automatically
  +without having to specify your own factory.
   
  +
   ---
   Jasper New Features:
   ---
  @@ -81,6 +88,33 @@
   when a web application wishes to use Xerces.  See the "KNOWN ISSUES" section
   for more information on this topic.
   
  +Run From WAR File:  Jasper has been modified so that it should be possible to
  +run web applications using JSP pages directly from an unpacked WAR file (or
  +any other repository that provides appropriate URL stream handlers).
  +
  +JSP API Changes:  Implement the JSP API changes that have been approved by
  +the JSR-053 Expert Group, and will appear in the next release of the
  +specification.
  +
  +
  +
  +Webapps New Features:
  +
  +
  +CompressionFilter:  A new example Filter implementation that performs
  +on-the-fly GZIP compression (if the client supports it, and if the response
  +is larger than a configurable size).  See the source file
  +"/WEB-INF/classes/compressionFilters/CompressionFilter.java" in the example
  +application.
  +
  +Manager Application:  The manager application has been enhanced to return the
  +status of each web application (running or stopped) and the number of current
  +active sessions, in the list command.  You can also request a list of the
  +session information for all active sessions.
  +
  +Server Side Includes:  Initial implementation of a pre-installed servlet that
  +performs server-side include processing on *.shtml files (except for #exec).
  +
   
   ==
   BUG FIXES AND IMPROVEMENTS:
  @@ -211,7 +245,47 @@
   DefaultServlet:  Make most methods protected instead of private, to ease
   subclassing.
   
  +EjbFactory:  Correct lookups of object factories for .
  +
  +Configuration Documentation:  Added configuration documentation details for the
  +, , and  elements.
  +
  +DirContextURLStreamHandler: Fix NullPointerExceptions that occurred during
  +openStream() operations under some circumstances.
  +
  +ApplicationContext:  Add support for immutable servlet context attributes
  +(i.e. you cannot remove or replace them), and apply this to the class loader
  +and class path passed to Jasper.
  +
  +DefaultServlet:  Add query parameters before sending a redirect.
  +
  +JDBCRealm: Correct password digest encoding so that it is compatible with the
  +techniques used in Tomcat 3.x.
  +
  +StandardContext:  Create JNDI entries for EJB references, resource references,
  +and resource environment references in the "java:comp/env" context (as the
  +J2EE spec requires), rather than "java:comp".
  +
  +Deployer:  Deployment semantics have been modified so that directories unpacked
  +as part of deployment will not be arbitrarily removed at undeployment time.
   
  +HttpRequestBase:  Correct implementation of isUserInRole() so that it properly
  +respects role name aliases defined with  elements.
  +
  +Bootstrap:  Rearrange the order in which repositories are added when Catalina
  +classloaders are created so that the "classes" directory (for a given class
  +loader) always overrides any JAR files in the corresponding "lib" directory.
  +This is consistent with the way web applica

Re: [VOTE] Tomcat 4.0 Beta 2 Release Tonight (Fixed Security Vulnerability)

[Glenn Nielsen]

"Craig R. McClanahan" wrote:
> 
> I'd like to propose that we create and publish a Tomcat 4.0 beta 2 release
> tonight, based on the current CVS code base.  The primary reason for the
> expedited schedule is that this code will include a fix for the "Tomcat
> may reveal script source code by URL trickery" security vulnerability, as
> well as lots of other bug fixes.
> 
> Comments?  Votes?
> 
> Craig McClanahan

+1

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContextMapper.java

[craigmcc]

craigmcc01/03/30 12:44:21

  Modified:catalina/src/share/org/apache/catalina/core
StandardContextMapper.java
  Log:
  Use RequestUtil.URLDecode() instead of URLDecoder.decode() in order to
  deal with character encoding issues correctly.
  
  Submitted by: Remy Maucherat <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.3   +6 -6  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextMapper.java
  
  Index: StandardContextMapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextMapper.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- StandardContextMapper.java2001/03/30 19:33:37 1.2
  +++ StandardContextMapper.java2001/03/30 20:44:20 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextMapper.java,v
 1.2 2001/03/30 19:33:37 craigmcc Exp $
  - * $Revision: 1.2 $
  - * $Date: 2001/03/30 19:33:37 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextMapper.java,v
 1.3 2001/03/30 20:44:20 craigmcc Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/03/30 20:44:20 $
*
* 
*
  @@ -65,7 +65,6 @@
   package org.apache.catalina.core;
   
   
  -import java.net.URLDecoder;
   import javax.servlet.http.HttpServletRequest;
   import org.apache.catalina.Container;
   import org.apache.catalina.Context;
  @@ -73,6 +72,7 @@
   import org.apache.catalina.Mapper;
   import org.apache.catalina.Request;
   import org.apache.catalina.Wrapper;
  +import org.apache.catalina.util.RequestUtil;
   import org.apache.catalina.util.StringManager;
   
   
  @@ -85,7 +85,7 @@
* StandardContext, because it relies on internal APIs.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.2 $ $Date: 2001/03/30 19:33:37 $
  + * @version $Revision: 1.3 $ $Date: 2001/03/30 20:44:20 $
*/
   
   public final class StandardContextMapper
  @@ -203,7 +203,7 @@
   // Decode the relative URI, because we will ultimately return both
   // servletPath and pathInfo as decoded strings
   try {
  -relativeURI = URLDecoder.decode(relativeURI);
  +relativeURI = RequestUtil.URLDecode(relativeURI);
   if (debug >= 1)
   context.log("Decoded relativeURI='" + relativeURI + "'");
   } catch (Exception e) {
  
  
  

RE: Stress Test problems with 3.2.1

[Cozianu, Costin]

Hi there,

I just wanted to report the same problem, apparently the situation is
improved in 3.2.2beta 2 .

What I had is that under 3.1 and 3.2.1 when stress loaded with 50 concurrent
users making request each second Tomcat leaked memory.
It would easily go to OutOfMemoryError, although I tried to help him by
adding a servlet that fired the GC.
So clearly it was a memory leak somewhere. 

I could have blamed my application for that but I did the same with other
containers.

Now the memory leak apparently has gone, but under the same stress Tomcat
generates some extraneous errors (the problem was there before):
"2001-03-30 12:32:38 - Ctx( /pictures ): IOException in: R( /pictures +
/ImgCache
/4/400/4003[cr_400]40030015.jpg + null) Connection reset by peer: socket
write e
rror"
Is there a way to report these errors with some extra debug info ?

Under no stress, the problem does not apear.

Also the CPU usage for tomcat (800Mhz/256MB RAM)under 35 requests/second
goes to 50-60%, 
while for resin 1.2.3 it bearly touches 15%.


So you're on the good path, but you still have a long way to go.


Hope this helps.

Costin


-Original Message-
From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 30, 2001 11:29 AM
To: [EMAIL PROTECTED]
Subject: RE: Stress Test problems with 3.2.1


Could you please try this test with Tomcat 3.2.2 beta 2?  I believe this
problem has been fixed in this release.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 30, 2001 1:08 PM
> To: [EMAIL PROTECTED]
> Subject: Stress Test problems with 3.2.1
>
>
> Hello,
> I have tc 3.2.1 installed on w2k server with iis5, sun hotspot 2.0 server
> mode and jdk 1.3.  I have been running this implementation
> successfully for
> the past several months with no problems.  I decided to perform a stress
> test to see how tc would handle it.
>
> 1. First test. 100 concurrent connections, each submitting a request to
> /examples/jsp/forward.jsp every 10 seconds.  This equated to 11
> requests per
> second.  I ran this test for 24 hours.  Results were perfect, no errors.
>
> 2. Second test.  same test as above with 200 concurrent connections.  This
> equated to 18 requests per second.  Ran for 5 minutes.  This time
> I received
> errors on 1% of the requests -- "500 - Internal Server Error".  I checked
> the Tomcat log and I am getting NullPointerExceptions from the jsp code
> followed by an ArrayIndexOutOfBoundsException at
> tomcat.util.SimplePool.put(SimplePool.java:112).  The redirect
> dll reports a
> few problems of not being able to handle the tc response.  I suspect tc
> could not deliver a response because of the internal errors.  Not sure.
>
> I go back to test 1 and everything is back to perfect.  Go to test 2 again
> and same errors.  As I lowered the number of requests per second, it gets
> better.  It did not matter if I had 300 concurrent connections as long as
> the request per second was around 11, everything worked fine.  Does anyone
> know what's up here?
>
> Thanks
> Mike
> [EMAIL PROTECTED]
>

RE: Stress Test problems with 3.2.1

[Remy Maucherat]

Quoting "Cozianu, Costin" <[EMAIL PROTECTED]>:

> Hi there,
> 
> I just wanted to report the same problem, apparently the situation is
> improved in 3.2.2beta 2 .
> 
> What I had is that under 3.1 and 3.2.1 when stress loaded with 50
> concurrent
> users making request each second Tomcat leaked memory.
> It would easily go to OutOfMemoryError, although I tried to help him by
> adding a servlet that fired the GC.
> So clearly it was a memory leak somewhere. 
> 
> I could have blamed my application for that but I did the same with
> other
> containers.
> 
> Now the memory leak apparently has gone, but under the same stress
> Tomcat
> generates some extraneous errors (the problem was there before):
> "2001-03-30 12:32:38 - Ctx( /pictures ): IOException in: R( /pictures +
> /ImgCache
> /4/400/4003[cr_400]40030015.jpg + null) Connection reset by peer:
> socket
> write e
> rror"
> Is there a way to report these errors with some extra debug info ?
> 
> Under no stress, the problem does not apear.
> 
> Also the CPU usage for tomcat (800Mhz/256MB RAM)under 35
> requests/second
> goes to 50-60%, 
> while for resin 1.2.3 it bearly touches 15%.
> 
> 
> So you're on the good path, but you still have a long way to go.

Maybe you should also test 3.3m2. It has big performance improvements, and is 
much more efficient memory wise than 3.2.

Remy

Re: [VOTE] Tomcat 4.0 Beta 2 Release Tonight (Fixed Security Vulnerability)

[horwat]

+1

Justy

- Original Message -
> I'd like to propose that we create and publish a Tomcat 4.0 beta 2 release
> tonight, based on the current CVS code base.  The primary reason for the
> expedited schedule is that this code will include a fix for the "Tomcat
> may reveal script source code by URL trickery" security vulnerability, as
> well as lots of other bug fixes.
>
> Comments?  Votes?
>
> Craig McClanahan
>
>
>

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpRequestBase.java

[Bill Claypool]

On Mon, Mar 26, 2001 at 08:02:18PM -, [EMAIL PROTECTED] wrote:
" craigmcc01/03/26 12:02:17
" 
"   Modified:catalina/src/share/org/apache/catalina/connector
" HttpRequestBase.java
"   Log:
"   Correct the implementation of HttpServletRequest.isUserInRole() so that it
"   properly respects role name aliases defined with .

Shouldn't this check for a mapped role first and only check for the
unmapped role if there is no mapping.

"   
"   PR: Bugzilla #1086
"   Submitted by:   [EMAIL PROTECTED]
"   
"   Revision  ChangesPath
"   1.18  +22 -12
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java
"   
"   Index: HttpRequestBase.java
"   ===
"   RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
"   retrieving revision 1.17
"   retrieving revision 1.18
"   diff -u -r1.17 -r1.18
"   --- HttpRequestBase.java2001/03/14 02:17:21 1.17
"   +++ HttpRequestBase.java2001/03/26 20:02:17 1.18
"   @@ -1,7 +1,7 @@
"/*
"   - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
 1.17 2001/03/14 02:17:21 craigmcc Exp $
"   - * $Revision: 1.17 $
"   - * $Date: 2001/03/14 02:17:21 $
"   + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpRequestBase.java,v
 1.18 2001/03/26 20:02:17 craigmcc Exp $
"   + * $Revision: 1.18 $
"   + * $Date: 2001/03/26 20:02:17 $
" *
" * 
" *
"   @@ -100,7 +100,7 @@
" * be implemented.
" *
" * @author Craig R. McClanahan
"   - * @version $Revision: 1.17 $ $Date: 2001/03/14 02:17:21 $
"   + * @version $Revision: 1.18 $ $Date: 2001/03/26 20:02:17 $
" */
"
"public class HttpRequestBase
"   @@ -1135,20 +1135,30 @@
" */
"public boolean isUserInRole(String role) {
"
"   -if (context == null)
"   +// Have we got an authenticated principal at all?
"   +if (userPrincipal == null)
"return (false);
"   -
"   -   // Respect role name translations in the deployment descriptor
"   -   String realRole = context.findRoleMapping(role);
"
"   -   // Determine whether the current user has this role
"   -   if (userPrincipal == null)
"   -   return (false);
"   +// Identify the Realm we will use for checking role assignmenets
"   +if (context == null)
"   +return (false);
"   Realm realm = context.getRealm();
"   if (realm == null)
"   return (false);
"
"   -   return (realm.hasRole(userPrincipal, realRole));
"   +// See if this role is assigned directly to the authenticated user
"   +if (realm.hasRole(userPrincipal, role))
"   +return (true);
"   +
"   +// Map the specified role if it is an alias defined in a
"   +//  element
"   +if (wrapper == null)
"   +return (false);
"   +String realRole = wrapper.findSecurityReference(role);
"   +if (realRole != null)
"   +return (realm.hasRole(userPrincipal, realRole));
"   +else
"   +return (false);
"
"}
"
"   
"   
"   

-- 
Bill Claypool   |  Seeing is believing in the things you see.
[EMAIL PROTECTED]   |Loving is believing in the ones you love.
1 916 928 6259  | RKBA!  -Margie Adam

Catalina Compiling error. class/method name mismatch between catalina classes reference calls and javax.servlet classes

[Hui Ye]

Title: Catalina Compiling error. class/method name mismatch between catalina classes reference calls and javax.servlet classes







Hi, all,


I downloaded latest catalina code off cvs and jakarta-servletapi-4.0-b1, along with other required stuff, and tried to compile and build it. However, there are class name and method mismatches between the two to prevent compiling going through. Example: 

org.apache.catalina.session.StandardSession and org.apache.catalina.core.ApplicationContext make reference to 

javax.servlet.http.HttpSessionAttributeListener. The class name within servletapi is 

javax.servlet.http.HttpSessionAttributesListener.



org.apache.catalina.core.ApplicationFilterConfig make calls to javax.servlet.filter.init(FilterConfig) and Filter.destroy() method. However, the methods aren't in javax.servlet.Filter interface


I am wandering which version of servlet api will match current catalina code? Any leads are appreciated.


Thanks in advance.


Hui

cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml

[craigmcc]

craigmcc01/03/30 13:20:05

  Modified:tester/src/bin tester.xml
   tester/web/WEB-INF web.xml
  Added:   tester/src/tester/org/apache/tester Decoding01.java
  Log:
  Add unit tests to validate URL decoding of getServletPath() and
  getPathInfo() values.
  
  Revision  ChangesPath
  1.25  +48 -2 jakarta-tomcat-4.0/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- tester.xml2001/03/26 20:04:37 1.24
  +++ tester.xml2001/03/30 21:20:02 1.25
  @@ -12,7 +12,7 @@
 
   
   
  -  
  +  
   
   
 
  @@ -137,6 +137,53 @@
 
   
   
  +  
  +
  +
  +
  +
  +
  +
  + 
  +
  +
  +
  +
  +
  +
  +
  +
  +
  + 
  +
  +
  +
  +
  +
  +
  +  
  +
  +
 
   
   
  @@ -521,7 +568,6 @@
   
  -
   
 
   
  
  
  
  1.1  
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Decoding01.java
  
  Index: Decoding01.java
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   * Copyright (c) 1999, 2000, 2001  The Apache Software Foundation.   *
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *notice, this list of conditions and the following disclaimer.  *
   *   *
   * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
   *notice,  this list of conditions  and the following  disclaimer in the *
   *documentation and/or other materials provided with the distribution.   *
   *   *
   * 3. The end-user documentation  included with the redistribution,  if any, *
   *must include the following acknowlegement: *
   *   *
   *   "This product includes  software developed  by the Apache  Software *
   *Foundation ."  *
   *   *
   *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 Software Foundation.*
   *   *
   * 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

cvs commit: jakarta-tomcat-4.0 README.txt

[craigmcc]

craigmcc01/03/30 13:23:25

  Modified:.README.txt
  Log:
  Add a note about downloading JavaMail and the activation framework in order
  to build the mail-related object factories.
  
  Revision  ChangesPath
  1.15  +5 -0  jakarta-tomcat-4.0/README.txt
  
  Index: README.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/README.txt,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- README.txt2001/03/24 01:23:21 1.14
  +++ README.txt2001/03/30 21:23:24 1.15
  @@ -43,6 +43,11 @@
 installed the distribution.  None of the standard JNDI providers are required
 unless you need them in your own applications.
   
  +* If you want to have support for the JavaMail object factories, you must
  +  download the JavaMail (Version 1.2 or later) and Java Activation Framework
  +  (Version 1.0.1 or later), and make sure that the "mail.jar" and
  +  "activation.jar" files, respectively, are on your CLASSPATH.
  +
   * If you want to build in support for JNDI JDBC DataSources you need to
 download the following packages and put their jar files in your classpath.
   
  
  
  

RE: Tomcat and IPv6

[GOMEZ Henri]

These question appeared some time ago and I think that Craig
said it depend on OS where java is running and certainly JVM support
on IPv6.

Rigth question may  be about JDK 1.3 support of IPv6 ?

>-Original Message-
>From: Ibrahim Haddad (LMC) [mailto:[EMAIL PROTECTED]]
>Sent: Friday, March 30, 2001 7:23 AM
>To: '[EMAIL PROTECTED]'
>Subject: Tomcat and IPv6
>
>
>Hello,
>
>I am working on IPv6 at Ericsson Research Canada. I would like
>to check if Tomcat has support for IPv6 addressing format.
>I would really appreciate your feedback.
>
>Thank you.
>
>--
>Ibrahim Haddad 
>Open Architecture Research Lab 
>
>

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

[craigmcc]

craigmcc01/03/30 13:38:48

  Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
  Log:
  Fix a further vulnerability related to the "may expose JSP source code"
  vulnerability.  Creative use of URL-encoded characters would also cause
  security constraints to be bypassed -- this is now corrected.
  
  Revision  ChangesPath
  1.10  +6 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
  
  Index: AuthenticatorBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- AuthenticatorBase.java2001/03/14 02:26:51 1.9
  +++ AuthenticatorBase.java2001/03/30 21:38:47 1.10
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
 1.9 2001/03/14 02:26:51 craigmcc Exp $
  - * $Revision: 1.9 $
  - * $Date: 2001/03/14 02:26:51 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
 1.10 2001/03/30 21:38:47 craigmcc Exp $
  + * $Revision: 1.10 $
  + * $Date: 2001/03/30 21:38:47 $
*
* 
*
  @@ -96,6 +96,7 @@
   import org.apache.catalina.deploy.LoginConfig;
   import org.apache.catalina.deploy.SecurityConstraint;
   import org.apache.catalina.util.LifecycleSupport;
  +import org.apache.catalina.util.RequestUtil;
   import org.apache.catalina.util.StringManager;
   import org.apache.catalina.valves.ValveBase;
   
  @@ -117,7 +118,7 @@
* requests.  Requests of any other type will simply be passed through.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.9 $ $Date: 2001/03/14 02:26:51 $
  + * @version $Revision: 1.10 $ $Date: 2001/03/30 21:38:47 $
*/
   
   
  @@ -671,6 +672,7 @@
String contextPath = hreq.getContextPath();
if (contextPath.length() > 0)
uri = uri.substring(contextPath.length());
  +uri = RequestUtil.URLDecode(uri); // Before checking constraints
String method = hreq.getMethod();
for (int i = 0; i < constraints.length; i++) {
if (debug >= 2)
  
  
  

cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B2.txt

[craigmcc]

craigmcc01/03/30 13:42:52

  Modified:.RELEASE-NOTES-4.0-B2.txt
  Log:
  Increase the visibility of the security vulnerabilities that were fixed, and
  add information about the increased scope of the second vulnerability, beyond
  what was originally reported.
  
  Revision  ChangesPath
  1.4   +18 -5 jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B2.txt
  
  Index: RELEASE-NOTES-4.0-B2.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B2.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- RELEASE-NOTES-4.0-B2.txt  2001/03/30 20:31:52 1.3
  +++ RELEASE-NOTES-4.0-B2.txt  2001/03/30 21:42:52 1.4
  @@ -3,13 +3,14 @@
   Release Notes
   =
   
  -$Id: RELEASE-NOTES-4.0-B2.txt,v 1.3 2001/03/30 20:31:52 craigmcc Exp $
  +$Id: RELEASE-NOTES-4.0-B2.txt,v 1.4 2001/03/30 21:42:52 craigmcc Exp $
   
   
   
   INTRODUCTION:
   
   
  +
   This document describes the changes that have been made in the current
   beta release of Apache Tomcat, relative to the previous release.
   
  @@ -20,11 +21,23 @@
   
   Please use project codes "Catalina" and "Jasper" for servlet-related and
   JSP-related bug reports, respectively.
  +
  +
  +
  +Important Security Notes:
  +
  +
  +This release includes fixes for two security vulnerabilities that have been
  +reported against Tomcat 4.0 beta 1:
  +
  +* A "cross site scripting" vulnerability would cause the enclosed JavaScript
  +  code to be executed (on the client) with a URL like:
  +
  +  http://localhost:8080/alert(document.cookie)http://localhost:8080/