DO NOT REPLY [Bug 15915] New: - Tomcat welcome page is invalid HTML

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15915

Tomcat welcome page is invalid HTML

   Summary: Tomcat welcome page is invalid HTML
   Product: Tomcat 4
   Version: 4.1.18
  Platform: All
OS/Version: All
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The Tomcat welcome page, that is the index.jsp page of the ROOT webapp, is invalid 
HTML, starts with an incorrect doctype, uses presentational tags and table-for-layout. 
Additionally, it fails accessibility checks.

I will attach a redesigned index.jsp and associated stylesheet. It is based on the 
page included with Tomcat 4.1.18 and fixes all of the above, as well as bug #15879. I 
have checked that it looks good on modern browsers and degrades gracefully on older 
ones and text browsers. Additional checks are very welcome, however (I don't own every 
browser in the world...).

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

DO NOT REPLY [Bug 15915] - Tomcat welcome page is invalid HTML

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15915

Tomcat welcome page is invalid HTML





--- Additional Comments From [EMAIL PROTECTED]  2003-01-09 09:30 ---
Created an attachment (id=4377)
Redesigned Tomcat welcome page

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

DO NOT REPLY [Bug 15915] - Tomcat welcome page is invalid HTML

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15915

Tomcat welcome page is invalid HTML





--- Additional Comments From [EMAIL PROTECTED]  2003-01-09 09:31 ---
Created an attachment (id=4380)
Stylesheet for redesigned welcome page

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

Re: Duplicate session IDs are *common*

[jean-frederic clere]

Craig R. McClanahan wrote:


On Wed, 8 Jan 2003, Aditya wrote:



Date: Wed, 08 Jan 2003 22:36:58 -0800
From: Aditya <[EMAIL PROTECTED]>
Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
To: Tomcat Developers List <[EMAIL PROTECTED]>
Subject: Re: Duplicate session IDs are *common*



On Wed, 08 Jan 2003 19:37:28 -0800, Costin Manolache <[EMAIL PROTECTED]> said:
The default is java.security.SecureRandom - and should give enough
randomness. There is a change on head ( that would work with 5.0 -
but it can be backported ) that allow you to use /dev/urandom ( or
another source - it can be a pipe or something like that ).


what about "hashing" the random part with System.currentTimeMillis()
so that even the vanishingly small probability of a collision is
avoided?  Or would that be too expensive?




The better check is the one that has been implemented -- if whatever
session id you just calculated (for a new session) is already in use, pick
another one.


I think that is done in ManagerBase.java





Adi



Craig


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






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

Re: Duplicate session IDs are *common*

[Remy Maucherat]

Schnitzer, Jeff wrote:

For whatever reason, be it the seed algorithm or the hashing algorithm
or something else that degenerates the randomness - the duplicate
session ID problem is very, very common.

I discovered this problem because a few of our users suddenly found
themselves with the sessions from administrative accounts.  Luckily they
alerted us instead of causing mayhem.  There were at least three
separate occasions of this in the last week - that we heard about.

We have also seen this a number of times with other game components -
users suddenly finding themselves logged in as other people.

It probably explains the recent post to tomcat-user included below.

Here at my company this problem caused about as much panic as a wildfire
breaking out in the machine room (read: LOTS).  I humbly suggest raising
the level of concern a bit; post a security bulletin, etc.


We have to make sure the problem is real before putting out any 
advisory. You should patch the ManagerBase class to the latest version 
to see if it helps (compile the latest version, and put it in 
$CATALINA_HOME/server/classes/org/apache/catalina/session). A compiled 
version is attached to this email if you can't get it easily.

However:
- We did not have any reports before 4.1.18 that the algorithm used was 
weak; it was actually believed it was not, and it had been around for a 
long time (I do not believe it was touched at all for months).
- A MD5 hash occurs after getting the SecureRandom. This looks like a 
mistake, and decreases the quality of the random a lot, but given the 
quality of MD5, that shouldn't be noticeable in the real world.
- If collisions *do* actyually happen, then it is a security problem and 
the patch to the StandardManager should fix it. However, it would also 
indicate that the ids generated can likely be guessed by an attacker, so 
we also have to fix the algorithm.

Remy


ManagerBase.class
Description: Binary data
--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: hello

[M]

Dan Agarlita wrote:
> 
> I want to know how can I modify the 404 Error page.
> I want to put another page. Is a param? Or I have to modify some classes
> ?
> 
> :) 10x, dan

I think you would be better off asking on the tomcat-users list...
And no you don't have to modify a class.

-- 
Regards,
M

Martin Sillence
PR Newswire

DL +44 (0)1865 78 5065
F  +44 (0)1865 78 5100
W  www.prnewswire.eu.com
---
Any views or opinions are solely those of the author and do not
necessarily represent those of PR Newswire Europe. The e-mail
contents are intended only for addressee and may contain
confidential and/or privileged material. If you are not the
intended recipient, please do not read, copy, use or disclose
this communication and notify the sender.

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

RE: hello

[Dan Agarlita]

I have the solution and it works, 
Thanks
ADan

-Original Message-
From: M [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, January 09, 2003 4:09 PM
To: Tomcat Developers List
Subject: Re: hello


Dan Agarlita wrote:
> 
> I want to know how can I modify the 404 Error page.
> I want to put another page. Is a param? Or I have to modify some 
> classes ?
> 
> :) 10x, dan

I think you would be better off asking on the tomcat-users list... And
no you don't have to modify a class.

-- 
Regards,
M

Martin Sillence
PR Newswire

DL +44 (0)1865 78 5065
F  +44 (0)1865 78 5100
W  www.prnewswire.eu.com
---
Any views or opinions are solely those of the author and do not
necessarily represent those of PR Newswire Europe. The e-mail contents
are intended only for addressee and may contain confidential and/or
privileged material. If you are not the intended recipient, please do
not read, copy, use or disclose this communication and notify the
sender.

--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

Re: Tomcat --> DB2 DBCP : authentication problem

[Carlos de Luna Saenz]

Works fine here with OS2 and DB2 7.1, no patches...
Greetings
 --- [EMAIL PROTECTED] escribió: > I am trying to
configure a connection from Tomcat
> 4.1.18 to DB2 7.2
> FixPack5 (NT, local DB2 client), and receive the
> following error message
> when trying to open a connection to the database:
> 
> org.apache.commons.dbcp.DbcpException:
> COM.ibm.db2.jdbc.DB2Exception:
> [IBM][CLI Driver] SQL0567N "SYSTEM" is not a valid
> authorization ID.
> SQLSTATE=42602
> 
> The exception is thrown when trying to create the
> connection in the
> following code:
> 
> javax.naming.InitialContext ctx = new
> javax.naming.InitialContext();
> javax.sql.DataSource ds =
> (javax.sql.DataSource)envx.lookup
> ("java:comp/env/jdbc/MyDB2");
> java.sql.Connection connection = ds.getConnection();
> 
> The resource definition in server.xml is as follows:
> 
>  auth="Container" type
> ="javax.sql.DataSource"/>
> 
> 
>   
>
> userdb2admin
>   
>   
>
> passworddb2admin
>   
>   
> driverClassName
>
> COM.ibm.db2.jdbc.app.DB2Driver
>   
>   
> url
>
> jdbc:db2:SAMPLE
>   
>   
> maxActive
> 8
>   
>   
> maxIdle
> 4
>   
>
>
> removeAbandoned
> true
>   
>   
>
> removeAbandonedTimeout
> 60
>   
>   
>
> logAbandoned
> true
>   
>   
> maxWait
> 1
>   
> 
> 
> I have tried to connect using the same username and
> password by manually
> creating a JDBC connection with the same driver (not
> using JNDI), and it
> works fine:
> 
>
Class.forName("com.ibm.db2.jcc.DB2Driver").newInstance();
> con = DriverManager.getConnection(
> "jdbc:db2:SAMPLE", "db2admin",
> "db2admin" );
> 
>  It seems that Tomcat does not send the correct
> credentials (the ones
> defined in the resourceparams in server.xml) when
> trying to connect to DB2
> (it seems to send "SYSTEM" rather than "db2admin").
> I have installed the
> necessary jakarta components for connection pooling
> and I have made the IBM
> driver classes available in the
> $CATALINA_HOME/common/lib directory. Hence,
> I suspect that the problem originates in the
> connection pooling part of
> Tomcat.
> 
> Have anyone experienced similar problems or have any
> idea about how to
> solve this?
> 
> Any suggestions are greatly appreciated.
> 
> Regards
> Vidar
> 
> B | vidar kongsli, consultant
> E | +47 982 19 329, [EMAIL PROTECTED]
> K | bekk consulting as, pb. 134 sentrum, 0102 oslo,
> K | www.bekk.no
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
>  

_
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. 
http://net.yahoo.com.mx

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

Email Rejected: Unknown or disallowed attachment type

[postmaster]

Received: from [198.76.25.3] (HELO nns.voyanttech.com)
  by voyanttech.com (CommuniGate Pro SMTP 3.4b3)
  with SMTP id 3409719 for [EMAIL PROTECTED]; Thu, 09 Jan 2003 03:57:23 -0700
Received: from exchange.sun.com (exchange.sun.com [192.18.33.10])
by nns.voyanttech.com (8.9.3+Sun/8.9.3) with SMTP id EAA06234
for <[EMAIL PROTECTED]>; Thu, 9 Jan 2003 04:45:32 -0500 (EST)
Received: (qmail 26016 invoked by uid 97); 9 Jan 2003 10:58:34 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Unsubscribe: 
List-Subscribe: 
List-Help: 
List-Post: 
List-Id: "Tomcat Developers List" 
Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Delivered-To: mailing list [EMAIL PROTECTED]
Received: (qmail 26004 invoked by uid 98); 9 Jan 2003 10:58:33 -
X-Antivirus: nagoya (v4218 created Aug 14 2002)
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 09 Jan 2003 10:53:50 +0100
From: Remy Maucherat <[EMAIL PROTECTED]>
Organization: ASF
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2) Gecko/20021126
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tomcat Developers List <[EMAIL PROTECTED]>
Subject: Re: Duplicate session IDs are *common*
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: multipart/mixed;
 boundary="060506040306030306060400"
X-Spam-Rating: localhost.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

--060506040306030306060400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Schnitzer, Jeff wrote:
> For whatever reason, be it the seed algorithm or the hashing algorithm
> or something else that degenerates the randomness - the duplicate
> session ID problem is very, very common.
> 
> I discovered this problem because a few of our users suddenly found
> themselves with the sessions from administrative accounts.  Luckily they
> alerted us instead of causing mayhem.  There were at least three
> separate occasions of this in the last week - that we heard about.
> 
> We have also seen this a number of times with other game components -
> users suddenly finding themselves logged in as other people.
> 
> It probably explains the recent post to tomcat-user included below.
> 
> Here at my company this problem caused about as much panic as a wildfire
> breaking out in the machine room (read: LOTS).  I humbly suggest raising
> the level of concern a bit; post a security bulletin, etc.

We have to make sure the problem is real before putting out any 
advisory. You should patch the ManagerBase class to the latest version 
to see if it helps (compile the latest version, and put it in 
$CATALINA_HOME/server/classes/org/apache/catalina/session). A compiled 
version is attached to this email if you can't get it easily.

However:
- We did not have any reports before 4.1.18 that the algorithm used was 
weak; it was actually believed it was not, and it had been around for a 
long time (I do not believe it was touched at all for months).
- A MD5 hash occurs after getting the SecureRandom. This looks like a 
mistake, and decreases the quality of the random a lot, but given the 
quality of MD5, that shouldn't be noticeable in the real world.
- If collisions *do* actyually happen, then it is a security problem and 
the patch to the StandardManager should fix it. However, it would also 
indicate that the ids generated can likely be guessed by an attacker, so 
we also have to fix the algorithm.

Remy

--060506040306030306060400
Content-Type: application/octet-stream;
 name="ManagerBase.class"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;

FOR ANTI-VIRUS SECURITY, THIS EMAIL HAS BEEN REJECTED.

REASON:
THIS EMAIL CONTAINED AN ATTACHMENT TYPE OF '.class' WHICH IS NOT PERMITTED.

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

DO NOT REPLY [Bug 15919] New: - strange loading error when using jsp/jstl & session-listener

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15919

strange loading error when using jsp/jstl & session-listener

   Summary: strange loading error when using jsp/jstl & session-
listener
   Product: Tomcat 4
   Version: 4.1.18
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


hi

i have a simple web-application using jsp sites with jstl (problem verified 
with latest nightly build and 1.0.2) and currently two simple listeners.

listener-part from web.xml


  mj.emag.SessionCounterListener



  mj.emag.SessionAuthListener


for development i use ant (1.5.1), so i have a fully automated ant 
install/reload/remove for my web-application.

when doing an ant install on a "clean" tomcat (everything clean) i get 
org.apache.jasper.JasperException: This absolute uri 
(http://java.sun.com/jstl/core) cannot be resolved in either web.xml or the 
jar files deployed with this application
with every jsp-file.

after commenting out both listeners in web.xml and doing a reload jsp works 
fine. now i must access every single jsp file. (for precompiling) then i can 
put in the listeners again and do another reload. --> Now everything works.

this behaviour is extremely strange, and i can't see why. (i think i'll remove 
my listeners and work with classic servlets... (*

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

Need help isolating severe Tomcat v4.1.18 bug

[Kristján Bjarni Guðmundsson]

Specs and variables:
Windows NT 4 SP 6 
Tomcat v4.1.18 
JDK v1.4.0_02
CATALINA_OPTS=-Xms128M -Xmx1024M 

At random intervals I get this error on console, it seems that the socket 
for port 80 is
suddenly closed and the server stops responding.
What steps can I take to get more information about why this error is 
occuring? 

SEVERE: Endpoint ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=80] 
ignored 
exception: java.net.SocketException: socket closed 
java.net.SocketException: socket closed 
at java.net.PlainSocketImpl.socketAccept(Native Method) 
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353) 
at java.net.ServerSocket.implAccept(ServerSocket.java:439) 
at java.net.ServerSocket.accept(ServerSocket.java:410) 
at 
org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(De 
faultServerSocketFactory.java:107) 
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoi 
nt.java:341) 
at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java 
:497) 
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP 
ool.java:530) 
at java.lang.Thread.run(Thread.java:536) 
8.1.2003 03:36:47 org.apache.tomcat.util.log.CommonLogHandler log 
SEVERE: Endpoint null shutdown due to exception: java.net.SocketException: 
Opera 
tion now in progress: create 
java.net.SocketException: Operation now in progress: create 
at java.net.ServerSocket.createImpl(ServerSocket.java:245) 
at java.net.ServerSocket.getImpl(ServerSocket.java:203) 
at java.net.ServerSocket.bind(ServerSocket.java:309) 
at java.net.ServerSocket.(ServerSocket.java:183) 
at java.net.ServerSocket.(ServerSocket.java:139) 
at 
org.apache.tomcat.util.net.DefaultServerSocketFactory.createSocket(De 
faultServerSocketFactory.java:96) 
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoi 
nt.java:389) 
at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java 
:497) 
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP 
ool.java:530) 
at java.lang.Thread.run(Thread.java:536) 
8.1.2003 03:36:47 org.apache.tomcat.util.log.CommonLogHandler log 
SEVERE: Caught exception trying to unlock accept. 
java.net.SocketException: Operation now in progress: create 
at java.net.Socket.createImpl(Socket.java:313) 
at java.net.Socket.(Socket.java:286) 
at java.net.Socket.(Socket.java:119) 
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.stopEndpoint(PoolTcpEndpoi 
nt.java:309) 
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoi 
nt.java:400) 
at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java 
:497) 
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP 
ool.java:530) 
at java.lang.Thread.run(Thread.java:536) 
8.1.2003 03:36:47 org.apache.tomcat.util.log.CommonLogHandler log 
SEVERE: Caught exception trying to close socket. 
java.lang.NullPointerException 
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.stopEndpoint(PoolTcpEndpoi 
nt.java:321) 
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoi 
nt.java:400) 
at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java 
:497) 
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP 
ool.java:530) 
at java.lang.Thread.run(Thread.java:536)

Re: Duplicate session IDs are *common*

[Eric Rescorla]

Remy Maucherat <[EMAIL PROTECTED]> writes:
> - A MD5 hash occurs after getting the SecureRandom. This looks like a
> mistake, and decreases the quality of the random a lot, but given the
> quality of MD5, that shouldn't be noticeable in the real world.
I think that the MD5 is pointless but it shouldn't decrease the
quality of the randomness to any interesting degree.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

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

[PATCH] Use JDK1.4 JSSE if available in jakarta-tomcat-util

[Conor MacNeill]

Hi,

The attached patch will update the Gump descriptor to make the JSSE package 
optional, so the JSSE package is not required when using JDK 1.4.

The util build file is also updated to use the JDK 1.4 jsse if available (or 
any JSSE on the classpath). The existing JSSE should continue to be used on 
pre JDK 1.4 builds.

This is all in the jakarta-tomcat-connectors repository

Thanks
Conor

Index: gump.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/gump.xml,v
retrieving revision 1.9
diff -3 -u -w -p -r1.9 gump.xml
--- gump.xml13 Nov 2002 00:12:49 -  1.9
+++ gump.xml9 Jan 2003 13:35:39 -
@@ -21,7 +21,7 @@
 
 
 
-
+
 
 
 
@@ -74,9 +74,7 @@
   
 org.apache.jk
 
-
-  
-
+
 
 
 
Index: util/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-connectors/util/build.xml,v
retrieving revision 1.15
diff -3 -u -w -p -r1.15 build.xml
--- util/build.xml  6 Jan 2003 18:36:18 -   1.15
+++ util/build.xml  9 Jan 2003 13:35:43 -
@@ -33,6 +33,7 @@
 
 
 
+
 
 
 

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java OutputBuffer.java

[remm]

remm2003/01/09 10:15:05

  Modified:coyote/src/java/org/apache/coyote/tomcat5
CoyoteResponse.java OutputBuffer.java
  Log:
  - Throw an exception when "creating" the writer if the encoding is invlaid.
  
  Revision  ChangesPath
  1.18  +5 -4  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java
  
  Index: CoyoteResponse.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- CoyoteResponse.java   3 Jan 2003 19:31:54 -   1.17
  +++ CoyoteResponse.java   9 Jan 2003 18:15:05 -   1.18
  @@ -629,6 +629,7 @@
   (sm.getString("coyoteResponse.getWriter.ise"));
   
   usingWriter = true;
  +outputBuffer.checkConverter();
   return writer;
   
   }
  
  
  
  1.5   +15 -1 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/OutputBuffer.java
  
  Index: OutputBuffer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/OutputBuffer.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- OutputBuffer.java 5 Jan 2003 11:20:18 -   1.4
  +++ OutputBuffer.java 9 Jan 2003 18:15:05 -   1.5
  @@ -581,7 +581,17 @@
   }
   
   
  -protected void setConverter() {
  +public void checkConverter() 
  +throws IOException {
  +
  +if (!gotEnc)
  +setConverter();
  +
  +}
  +
  +
  +protected void setConverter() 
  +throws IOException {
   
   if (coyoteResponse != null)
   enc = coyoteResponse.getCharacterEncoding();
  @@ -594,6 +604,9 @@
   enc = DEFAULT_ENCODING;
   conv = (C2BConverter) encoders.get(enc);
   if (conv == null) {
  +conv = new C2BConverter(bb, enc);
  +encoders.put(enc, conv);
  +/*
   try {
   conv = new C2BConverter(bb, enc);
   encoders.put(enc, conv);
  @@ -608,6 +621,7 @@
   }
   }
   }
  +*/
   }
   }
   
  
  
  

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

Re: Duplicate session IDs are *common*

[Dirk-Willem van Gulik]

On 9 Jan 2003, Eric Rescorla wrote:

> Remy Maucherat <[EMAIL PROTECTED]> writes:
> > - A MD5 hash occurs after getting the SecureRandom. This looks like a
> > mistake, and decreases the quality of the random a lot, but given the
> > quality of MD5, that shouldn't be noticeable in the real world.

> I think that the MD5 is pointless but it shouldn't decrease the
> quality of the randomness to any interesting degree.

It makes the value less predictible. But as it adds no information (and
one could argule only looses it if the initial information had more than
128bits of randonm (which is highly unlikely)) it does not change the
'randomness' itself.

You propably want to argue -what- sort of randomness you want

-   unpredicable session id's
-   a unique session id
-   always a guaranteed different session id.
-   session id with no information.

Pick one, pick two, but if you pick three or more you are going to have a
hard time.

Dw


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

Re: Duplicate session IDs are *common*

[Eric Rescorla]

Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes:

> On 9 Jan 2003, Eric Rescorla wrote:
> 
> > Remy Maucherat <[EMAIL PROTECTED]> writes:
> > > - A MD5 hash occurs after getting the SecureRandom. This looks like a
> > > mistake, and decreases the quality of the random a lot, but given the
> > > quality of MD5, that shouldn't be noticeable in the real world.
> 
> > I think that the MD5 is pointless but it shouldn't decrease the
> > quality of the randomness to any interesting degree.
> 
> It makes the value less predictible.
Not if the initial value came out of SecureRandom in the first
place.

> You propably want to argue -what- sort of randomness you want
> 
> - unpredicable session id's
> - a unique session id
> - always a guaranteed different session id.
> - session id with no information.
> 
> Pick one, pick two, but if you pick three or more you are going to have a
> hard time.
If you use a cryptographically secure PRNG you can get 1,2,4 
and 3 with very high probability. The probability of two
properly randomly generated 128-bit numbers colliding is
negligible.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java StandardManager.java

[costin]

costin  2003/01/09 11:09:33

  Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java StandardManager.java
  Log:
  Few changes to give more info in the jmx console.
  
  Switched StandardManager to c-l. There are still few dozens files that
  need to be converted - and we need to find a naming scheme for the logs
  that includes the host/path/component.
  
  The additions provide info about detected duplicates, total number of
  sessions that were generated, number of sessions that expired, number
  of sessions that failed because of maxActive.
  
  Also operations to show the sessions and get basic info ( expire ).
  I think this would simplify some debugging and be more informative.
  
  Revision  ChangesPath
  1.11  +125 -46   
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
  
  Index: ManagerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- ManagerBase.java  1 Jan 2003 06:26:32 -   1.10
  +++ ManagerBase.java  9 Jan 2003 19:09:33 -   1.11
  @@ -1,7 +1,4 @@
   /*
  - * $Header$
  - * $Revision$
  - * $Date$
*
* 
*
  @@ -75,16 +72,16 @@
   import java.security.MessageDigest;
   import java.security.NoSuchAlgorithmException;
   import java.security.PrivilegedAction;
  -import java.util.ArrayList;
  -import java.util.HashMap;
  -import java.util.Random;
  +import java.util.*;
  +
   import org.apache.catalina.Container;
   import org.apache.catalina.DefaultContext;
   import org.apache.catalina.Engine;
  -import org.apache.catalina.Logger;
   import org.apache.catalina.Manager;
   import org.apache.catalina.Session;
   import org.apache.catalina.util.StringManager;
  +import org.apache.commons.logging.Log;
  +import org.apache.commons.logging.LogFactory;
   
   
   /**
  @@ -97,8 +94,7 @@
*/
   
   public abstract class ManagerBase implements Manager {
  -private static org.apache.commons.logging.Log log=
  -org.apache.commons.logging.LogFactory.getLog( ManagerBase.class );
  +protected Log log = LogFactory.getLog(ManagerBase.class);
   
   // - Instance Variables
   
  @@ -211,6 +207,13 @@
*/
   protected HashMap sessions = new HashMap();
   
  +// Number of sessions created by this manager
  +protected int sessionCounter=0;
  +
  +protected int maxActive=0;
  +
  +// number of duplicated session ids - anything >0 means we have problems
  +protected int duplicates=0;
   
   /**
* The string manager for this package.
  @@ -218,7 +221,6 @@
   protected static StringManager sm =
   StringManager.getManager(Constants.Package);
   
  -
   /**
* The property change support for this component.
*/
  @@ -245,7 +247,6 @@
   
   // - Properties
   
  -
   /**
* Return the message digest algorithm for this Manager.
*/
  @@ -290,7 +291,8 @@
   Container oldContainer = this.container;
   this.container = container;
   support.firePropertyChange("container", oldContainer, this.container);
  -
  +// TODO: find a good scheme for the log names
  +//log=LogFactory.getLog("tomcat.manager." + container.getName());
   }
   
   
  @@ -339,6 +341,12 @@
   
   }
   
  +/** Returns the name of the implementation class.
  + */
  +public String getClassName() {
  +return this.getClass().getName();
  +}
  +
   
   /**
* Return the MessageDigest object to be used for calculating
  @@ -515,6 +523,10 @@
   }
   }
   
  +public String getRandomFile() {
  +return devRandomSource;
  +}
  +
   
   /**
* Return the random number generator instance we should use for
  @@ -594,8 +606,10 @@
   
   synchronized (sessions) {
   sessions.put(session.getId(), session);
  +if( sessions.size() > maxActive ) {
  +maxActive=sessions.size();
  +}
   }
  -
   }
   
   
  @@ -640,6 +654,7 @@
   }
   synchronized (sessions) {
   while (sessions.get(sessionId) != null){ // Guarantee uniqueness
  +duplicates++;
   sessionId = generateSessionId();
   // @todo Move appending of jvmRoute generateSessionId()???
   if (jvmRoute != null) {
  @@ -649,6 +664,7 @@
   }
   
   session.setId(sessionId);
  +sessionCounter++;
   
   return (session);
   
  @@ -838,23 +854,10 @@
* Log a message on th

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/sessionManagerBase.java StandardManager.java

[Tim Funk]

Am I correct that this patch removes the explicit imports from java.util 
and adds this:
import java.util.*


-Tim

[EMAIL PROTECTED] wrote:
costin  2003/01/09 11:09:33

  Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java StandardManager.java
  Log:
  Few changes to give more info in the jmx console.
  
  Switched StandardManager to c-l. There are still few dozens files that
  need to be converted - and we need to find a naming scheme for the logs
  that includes the host/path/component.
  
  The additions provide info about detected duplicates, total number of
  sessions that were generated, number of sessions that expired, number
  of sessions that failed because of maxActive.
  
  Also operations to show the sessions and get basic info ( expire ).
  I think this would simplify some debugging and be more informative.
  
  Revision  ChangesPath
  1.11  +125 -46   jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
  
  Index: ManagerBase.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- ManagerBase.java	1 Jan 2003 06:26:32 -	1.10
  +++ ManagerBase.java	9 Jan 2003 19:09:33 -	1.11
  @@ -1,7 +1,4 @@
   /*
  - * $Header$
  - * $Revision$
  - * $Date$
*
* 
*
  @@ -75,16 +72,16 @@
   import java.security.MessageDigest;
   import java.security.NoSuchAlgorithmException;
   import java.security.PrivilegedAction;
  -import java.util.ArrayList;
  -import java.util.HashMap;
  -import java.util.Random;
  +import java.util.*;
  +
   import org.apache.catalina.Container;
   import org.apache.catalina.DefaultContext;
   import org.apache.catalina.Engine;
  -import org.apache.catalina.Logger;
   import org.apache.catalina.Manager;
   import org.apache.catalina.Session;
   import org.apache.catalina.util.StringManager;
  +import org.apache.commons.logging.Log;
  +import org.apache.commons.logging.LogFactory;
   
   
   /**
  @@ -97,8 +94,7 @@
*/
   
   public abstract class ManagerBase implements Manager {
  -private static org.apache.commons.logging.Log log=
  -org.apache.commons.logging.LogFactory.getLog( ManagerBase.class );
  +protected Log log = LogFactory.getLog(ManagerBase.class);
   
   // - Instance Variables
   
  @@ -211,6 +207,13 @@
*/
   protected HashMap sessions = new HashMap();
   
  +// Number of sessions created by this manager
  +protected int sessionCounter=0;
  +
  +protected int maxActive=0;
  +
  +// number of duplicated session ids - anything >0 means we have problems
  +protected int duplicates=0;
   
   /**
* The string manager for this package.
  @@ -218,7 +221,6 @@
   protected static StringManager sm =
   StringManager.getManager(Constants.Package);
   
  -
   /**
* The property change support for this component.
*/
  @@ -245,7 +247,6 @@
   
   // - Properties
   
  -
   /**
* Return the message digest algorithm for this Manager.
*/
  @@ -290,7 +291,8 @@
   Container oldContainer = this.container;
   this.container = container;
   support.firePropertyChange("container", oldContainer, this.container);
  -
  +// TODO: find a good scheme for the log names
  +//log=LogFactory.getLog("tomcat.manager." + container.getName());
   }
   
   
  @@ -339,6 +341,12 @@
   
   }
   
  +/** Returns the name of the implementation class.
  + */
  +public String getClassName() {
  +return this.getClass().getName();
  +}
  +
   
   /**
* Return the MessageDigest object to be used for calculating
  @@ -515,6 +523,10 @@
   }
   }
   
  +public String getRandomFile() {
  +return devRandomSource;
  +}
  +
   
   /**
* Return the random number generator instance we should use for
  @@ -594,8 +606,10 @@
   
   synchronized (sessions) {
   sessions.put(session.getId(), session);
  +if( sessions.size() > maxActive ) {
  +maxActive=sessions.size();
  +}
   }
  -
   }
   
   
  @@ -640,6 +654,7 @@
   }
   synchronized (sessions) {
   while (sessions.get(sessionId) != null){ // Guarantee uniqueness
  +duplicates++;
   sessionId = generateSessionId();
   // @todo Move appending of jvmRoute generateSessionId()???
   if (jvmRoute != null) {
  @@ -649,6 +664,7 @@
   }
   
   session.setId(sessio

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/sessionManagerBase.java StandardManager.java

[Jeanfrancois Arcand]

Hi Costin,

I was under the impression, as a convention, that we don't import using 
* (java.util.*). I find it more easier when all the classes are 
namedand from what I'm seeing, seems * is not used (at least on 
classes that I have worked on)

-- Jeanfrancois

[EMAIL PROTECTED] wrote:

costin  2003/01/09 11:09:33

 Modified:catalina/src/share/org/apache/catalina/session
   ManagerBase.java StandardManager.java
 Log:
 Few changes to give more info in the jmx console.
 
 Switched StandardManager to c-l. There are still few dozens files that
 need to be converted - and we need to find a naming scheme for the logs
 that includes the host/path/component.
 
 The additions provide info about detected duplicates, total number of
 sessions that were generated, number of sessions that expired, number
 of sessions that failed because of maxActive.
 
 Also operations to show the sessions and get basic info ( expire ).
 I think this would simplify some debugging and be more informative.
 
 Revision  ChangesPath
 1.11  +125 -46   jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
 
 Index: ManagerBase.java
 ===
 RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
 retrieving revision 1.10
 retrieving revision 1.11
 diff -u -r1.10 -r1.11
 --- ManagerBase.java	1 Jan 2003 06:26:32 -	1.10
 +++ ManagerBase.java	9 Jan 2003 19:09:33 -	1.11
 @@ -1,7 +1,4 @@
  /*
 - * $Header$
 - * $Revision$
 - * $Date$
   *
   * 
   *
 @@ -75,16 +72,16 @@
  import java.security.MessageDigest;
  import java.security.NoSuchAlgorithmException;
  import java.security.PrivilegedAction;
 -import java.util.ArrayList;
 -import java.util.HashMap;
 -import java.util.Random;
 +import java.util.*;
 +
  import org.apache.catalina.Container;
  import org.apache.catalina.DefaultContext;
  import org.apache.catalina.Engine;
 -import org.apache.catalina.Logger;
  import org.apache.catalina.Manager;
  import org.apache.catalina.Session;
  import org.apache.catalina.util.StringManager;
 +import org.apache.commons.logging.Log;
 +import org.apache.commons.logging.LogFactory;
  
  
  /**
 @@ -97,8 +94,7 @@
   */
  
  public abstract class ManagerBase implements Manager {
 -private static org.apache.commons.logging.Log log=
 -org.apache.commons.logging.LogFactory.getLog( ManagerBase.class );
 +protected Log log = LogFactory.getLog(ManagerBase.class);
  
  // - Instance Variables
  
 @@ -211,6 +207,13 @@
   */
  protected HashMap sessions = new HashMap();
  
 +// Number of sessions created by this manager
 +protected int sessionCounter=0;
 +
 +protected int maxActive=0;
 +
 +// number of duplicated session ids - anything >0 means we have problems
 +protected int duplicates=0;
  
  /**
   * The string manager for this package.
 @@ -218,7 +221,6 @@
  protected static StringManager sm =
  StringManager.getManager(Constants.Package);
  
 -
  /**
   * The property change support for this component.
   */
 @@ -245,7 +247,6 @@
  
  // - Properties
  
 -
  /**
   * Return the message digest algorithm for this Manager.
   */
 @@ -290,7 +291,8 @@
  Container oldContainer = this.container;
  this.container = container;
  support.firePropertyChange("container", oldContainer, this.container);
 -
 +// TODO: find a good scheme for the log names
 +//log=LogFactory.getLog("tomcat.manager." + container.getName());
  }
  
  
 @@ -339,6 +341,12 @@
  
  }
  
 +/** Returns the name of the implementation class.
 + */
 +public String getClassName() {
 +return this.getClass().getName();
 +}
 +
  
  /**
   * Return the MessageDigest object to be used for calculating
 @@ -515,6 +523,10 @@
  }
  }
  
 +public String getRandomFile() {
 +return devRandomSource;
 +}
 +
  
  /**
   * Return the random number generator instance we should use for
 @@ -594,8 +606,10 @@
  
  synchronized (sessions) {
  sessions.put(session.getId(), session);
 +if( sessions.size() > maxActive ) {
 +maxActive=sessions.size();
 +}
  }
 -
  }
  
  
 @@ -640,6 +654,7 @@
  }
  synchronized (sessions) {
  while (sessions.get(sessionId) != null){ // Guarantee uniqueness
 +duplicates++;
  sessionId = generateSessionId();
  // @todo Move appending of jvmRoute generateSessionId()???
  if (jvmRoute != null) {
 @@ -649,6 +664,7 @@
  }
  
  session.setId(session

Bug with JAASRealm/NT Domain?

[Sam Ewing]

I am using JAASRealm with the NT Login module. My
Realm configuration from
server.xml (tomcat 4.1.18) is:




I then modified the web.xml for the admin and manager
applications, changing it to my NT domain name and
restarted Tomcat.

On browsing to the admin and manager application, I
merely get an empty web page and no error... the log
files also dont have any error indication. Am I
missing something, or is this a bug? I tried posting
some JAAS Realm questions on tomcat-user... but guess
there arent a lot of users using JAASRealms.

TIA

/s

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

Re: Bug with JAASRealm/NT Domain?

[Sam Ewing]

Even added a jaas.conf in my user.dir with  the
following entry...

Tomcat {
   com.sun.security.auth.module.NTLoginModule
required;
};


--- Sam Ewing <[EMAIL PROTECTED]> wrote:
> 
> 
> I am using JAASRealm with the NT Login module. My
> Realm configuration from
> server.xml (tomcat 4.1.18) is:
> 
> 
>  className="org.apache.catalina.realm.JAASRealm"
> debug="99"
>
roleClassNames="com.sun.security.auth.NTDomainPrincipal"
>  
>
userClassNames="com.sun.security.auth.NTUserPrincipal"
> />
> 
> I then modified the web.xml for the admin and
> manager
> applications, changing it to my NT domain name and
> restarted Tomcat.
> 
> On browsing to the admin and manager application, I
> merely get an empty web page and no error... the log
> files also dont have any error indication. Am I
> missing something, or is this a bug? I tried posting
> some JAAS Realm questions on tomcat-user... but
> guess
> there arent a lot of users using JAASRealms.
> 
> TIA
> 
> /s
> 
> __
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up
> now.
> http://mailplus.yahoo.com
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java StandardManager.java

[Costin Manolache]

I'll fix it. That's what happens when you let a program do the editing for
you.

Costin

Jeanfrancois Arcand wrote:

> Hi Costin,
> 
>  I was under the impression, as a convention, that we don't import using
> * (java.util.*). I find it more easier when all the classes are
> namedand from what I'm seeing, seems * is not used (at least on
> classes that I have worked on)
> 
> -- Jeanfrancois
> 
> [EMAIL PROTECTED] wrote:
> 
>>costin  2003/01/09 11:09:33
>>
>>  Modified:catalina/src/share/org/apache/catalina/session
>>ManagerBase.java StandardManager.java
>>  Log:
>>  Few changes to give more info in the jmx console.
>>  
>>  Switched StandardManager to c-l. There are still few dozens files that
>>  need to be converted - and we need to find a naming scheme for the logs
>>  that includes the host/path/component.
>>  
>>  The additions provide info about detected duplicates, total number of
>>  sessions that were generated, number of sessions that expired, number
>>  of sessions that failed because of maxActive.
>>  
>>  Also operations to show the sessions and get basic info ( expire ).
>>  I think this would simplify some debugging and be more informative.
>>  
>>  Revision  ChangesPath
>>  1.11  +125 -46  
>>  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
>>  
>>  Index: ManagerBase.java
>>  ===
>>  RCS file:
>>  
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
>>  retrieving revision 1.10 retrieving revision 1.11
>>  diff -u -r1.10 -r1.11
>>  --- ManagerBase.java1 Jan 2003 06:26:32 -   1.10
>>  +++ ManagerBase.java9 Jan 2003 19:09:33 -   1.11
>>  @@ -1,7 +1,4 @@
>>   /*
>>  - * $Header$
>>  - * $Revision$
>>  - * $Date$
>>*
>>* 
>>*
>>  @@ -75,16 +72,16 @@
>>   import java.security.MessageDigest;
>>   import java.security.NoSuchAlgorithmException;
>>   import java.security.PrivilegedAction;
>>  -import java.util.ArrayList;
>>  -import java.util.HashMap;
>>  -import java.util.Random;
>>  +import java.util.*;
>>  +
>>   import org.apache.catalina.Container;
>>   import org.apache.catalina.DefaultContext;
>>   import org.apache.catalina.Engine;
>>  -import org.apache.catalina.Logger;
>>   import org.apache.catalina.Manager;
>>   import org.apache.catalina.Session;
>>   import org.apache.catalina.util.StringManager;
>>  +import org.apache.commons.logging.Log;
>>  +import org.apache.commons.logging.LogFactory;
>>   
>>   
>>   /**
>>  @@ -97,8 +94,7 @@
>>*/
>>   
>>   public abstract class ManagerBase implements Manager {
>>  -private static org.apache.commons.logging.Log log=
>>  -org.apache.commons.logging.LogFactory.getLog( ManagerBase.class
>>  );
>>  +protected Log log = LogFactory.getLog(ManagerBase.class);
>>   
>>   // - Instance
>>   Variables
>>   
>>  @@ -211,6 +207,13 @@
>>*/
>>   protected HashMap sessions = new HashMap();
>>   
>>  +// Number of sessions created by this manager
>>  +protected int sessionCounter=0;
>>  +
>>  +protected int maxActive=0;
>>  +
>>  +// number of duplicated session ids - anything >0 means we have
>>  problems
>>  +protected int duplicates=0;
>>   
>>   /**
>>* The string manager for this package.
>>  @@ -218,7 +221,6 @@
>>   protected static StringManager sm =
>>   StringManager.getManager(Constants.Package);
>>   
>>  -
>>   /**
>>* The property change support for this component.
>>*/
>>  @@ -245,7 +247,6 @@
>>   
>>   // -
>>   Properties
>>   
>>  -
>>   /**
>>* Return the message digest algorithm for this Manager.
>>*/
>>  @@ -290,7 +291,8 @@
>>   Container oldContainer = this.container;
>>   this.container = container;
>>   support.firePropertyChange("container", oldContainer,
>>   this.container);
>>  -
>>  +// TODO: find a good scheme for the log names
>>  +//log=LogFactory.getLog("tomcat.manager." +
>>  container.getName());
>>   }
>>   
>>   
>>  @@ -339,6 +341,12 @@
>>   
>>   }
>>   
>>  +/** Returns the name of the implementation class.
>>  + */
>>  +public String getClassName() {
>>  +return this.getClass().getName();
>>  +}
>>  +
>>   
>>   /**
>>* Return the MessageDigest object to be used for calculating
>>  @@ -515,6 +523,10 @@
>>   }
>>   }
>>   
>>  +public String getRandomFile() {
>>  +return devRandomSource;
>>  +}
>>  +
>>   
>>   /**
>>* Return the random number generator instance we should use for
>>  @@ -594,8 +606,10 @@
>>   
>>   synchronized (sessions

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java

[costin]

costin  2003/01/09 13:15:46

  Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
  Log:
  Fix the imports.
  
  Hope the tab police won't give me another ticket.
  
  Revision  ChangesPath
  1.12  +7 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
  
  Index: ManagerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- ManagerBase.java  9 Jan 2003 19:09:33 -   1.11
  +++ ManagerBase.java  9 Jan 2003 21:15:46 -   1.12
  @@ -64,15 +64,19 @@
   
   import java.beans.PropertyChangeListener;
   import java.beans.PropertyChangeSupport;
  -import java.io.IOException;
   import java.io.DataInputStream;
   import java.io.File;
   import java.io.FileInputStream;
  +import java.io.IOException;
   import java.security.AccessController;
   import java.security.MessageDigest;
   import java.security.NoSuchAlgorithmException;
   import java.security.PrivilegedAction;
  -import java.util.*;
  +import java.util.ArrayList;
  +import java.util.Date;
  +import java.util.HashMap;
  +import java.util.Iterator;
  +import java.util.Random;
   
   import org.apache.catalina.Container;
   import org.apache.catalina.DefaultContext;
  
  
  

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

Re: Bug with JAASRealm/NT Domain?

[Sam Ewing]

I tried debugging the JAASRealm. This is where things
go wrong- 

 public Principal authenticate(String username, String
credentials) {

 ...
 loginContext = new LoginContext
 (appName, new JAASCallbackHandler(this, username,
 
credentials))
...

  The JAACallbackHandler object gets built, but the
method never returns from the LoginContext connector-
not even an exception.

 Help!

/s

--- Sam Ewing <[EMAIL PROTECTED]> wrote:
> Even added a jaas.conf in my user.dir with  the
> following entry...
> 
> Tomcat {
>com.sun.security.auth.module.NTLoginModule
> required;
> };
> 
> 
> --- Sam Ewing <[EMAIL PROTECTED]> wrote:
> > 
> > 
> > I am using JAASRealm with the NT Login module. My
> > Realm configuration from
> > server.xml (tomcat 4.1.18) is:
> > 
> > 
> >  > className="org.apache.catalina.realm.JAASRealm"
> > debug="99"
> >
>
roleClassNames="com.sun.security.auth.NTDomainPrincipal"
> >  
> >
>
userClassNames="com.sun.security.auth.NTUserPrincipal"
> > />
> > 
> > I then modified the web.xml for the admin and
> > manager
> > applications, changing it to my NT domain name and
> > restarted Tomcat.
> > 
> > On browsing to the admin and manager application,
> I
> > merely get an empty web page and no error... the
> log
> > files also dont have any error indication. Am I
> > missing something, or is this a bug? I tried
> posting
> > some JAAS Realm questions on tomcat-user... but
> > guess
> > there arent a lot of users using JAASRealms.
> > 
> > TIA
> > 
> > /s
> > 
> > __
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up
> > now.
> > http://mailplus.yahoo.com
> > 
> > --
> > To unsubscribe, e-mail:  
> > 
> > For additional commands, e-mail:
> > 
> > 
> 
> 
> __
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up
> now.
> http://mailplus.yahoo.com
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

Connector-HOWTO

[Bishr Tabbaa]

Tomcat-Dev,

I am trying to develop my own connector for Tomcat 4.x.  I have strived to
follow the programmatic conventions in the Coyote package such that my
package contains a connectorimpl, connectionprocessorimpl,
servletoutputstreamimpl, servletinputstream, requestimpl, and responseimpl.
I added an entry to server.xml, started tomcat, and encountered the
following error:

ServerLifecycleListener: createMBeans: MBeanException
java.lang.Exception: ManagedBean is not found with VigilentConnector
at
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:224
)
...
at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

Then, I added an entry to 'mbeans-descriptors.xml' inside catalina.jar
associating an MBean with my connector.



  

I started tomcat again and encountered the following error:

ServerLifecycleListener: createMBeans: Throwable
javax.management.MalformedObjectNameException: Cannot create object name for
com.netiq.servlet.VigilentConnector@3db503
at
org.apache.catalina.mbeans.MBeanUtils.createObjectName(MBeanUtils.jav
a:873)
at
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:231
)

at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)

I looked at the 4.1.18 src code of MBeanUtils.java and discovered that the
instanceof operator is applied to concrete classes!  I prefer not to change
the source, but it appears that this is the only available fork in the road.
Is there something that I am missing?

Thanks,
Bishr

-
Bishr Tabbaa
NetIQ Corporation
1233 West Loop South # 1800
Houston, TX 77027
Toll Free: 1-888-400-2834
Fax:   713-523-6393
Direct:713-860-9726
Mobile:832-651-0610
[EMAIL PROTECTED]
- 
Note:  The information contained in this message may be privileged and
confidential and protected from disclosure.  If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited.  Thank you.  NetIQ, Inc.

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

DO NOT REPLY [Bug 15937] - Misleading error message produced if jsp:body is not a child of a standard or custom action.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15937

Misleading error message produced if jsp:body is not a child of a standard or custom 
action.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

[luehe]

luehe   2003/01/09 15:54:41

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties
  Log:
  Fixed 15937: Misleading error message produced if jsp:body is not a
  child of a standard or custom action.
  
  Revision  ChangesPath
  1.53  +5 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- Parser.java   18 Dec 2002 23:18:21 -  1.52
  +++ Parser.java   9 Jan 2003 23:54:40 -   1.53
  @@ -1196,6 +1196,8 @@
parseElement(parent);
} else if (reader.matches("attribute")) {
err.jspError(start, "jsp.error.namedAttribute.invalidUse");
  + } else if (reader.matches("body")) {
  + err.jspError(start, "jsp.error.jspbody.invalidUse");
} else if (reader.matches("fallback")) {
err.jspError(start, "jsp.error.fallback.invalidUse");
} else if (reader.matches("params")) {
  
  
  
  1.77  +3 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
  
  Index: messages.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
  retrieving revision 1.76
  retrieving revision 1.77
  diff -u -r1.76 -r1.77
  --- messages.properties   3 Jan 2003 13:26:44 -   1.76
  +++ messages.properties   9 Jan 2003 23:54:40 -   1.77
  @@ -106,7 +106,8 @@
   jsp.error.param.invalidUse=The jsp:param action must not be used outside the 
jsp:include, jsp:forward, or jsp:params elements
   jsp.error.params.invalidUse=jsp:params must be a direct child of jsp:plugin
   jsp.error.fallback.invalidUse=jsp:fallback must be a direct child of jsp:plugin
  -jsp.error.namedAttribute.invalidUse=jsp:attribute must be a sublement of a standard 
or custom action
  +jsp.error.namedAttribute.invalidUse=jsp:attribute must be the subelement of a 
standard or custom action
  +jsp.error.jspbody.invalidUse=jsp:body must be the subelement of a standard or 
custom action
   jsp.error.closeindividualparam=param tag needs to be closed with \"/>\"
   jsp.error.closeparams=param tag needs to be closed with /params
   jsp.error.params.emptyBody=jsp:params must contain at least one nested jsp:param
  
  
  

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

DO NOT REPLY [Bug 15938] New: - regex not matching uri's with isapi_redirector2.dll 2.0.2

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15938

regex not matching uri's with isapi_redirector2.dll 2.0.2

   Summary: regex not matching uri's with isapi_redirector2.dll
2.0.2
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


PCRE 3.9 reports a match between $localhost/students/(.+)?/servlet/(.+)?$ and 
localhost/students/username/servlet/HelloWorldExample, however 
isapi_redirector2.dll reports no match.

When requesting http://localhost/students/username/servlet/HelloWorldExample 
through isapi_redirector2.dll, none of the following workers2.properties uri's 
report a match despite reporting a match with PCRE 3.9:

$localhost/students/(.+)?/servlet/(.+)?$
$http://localhost/students/(.+)?/servlet/(.+)?$
$/students/(.+)?/servlet/(.+)?$
$localhost/students/(.*)?/servlet/(.*)?$
$http://localhost/students/(.*)?/servlet/(.*)?$
$/students/(.*)?/servlet/(.*)?$
$(.*)?$

I don't know a whole lot about PCRE, so I first figured it was me. But when the 
developers example of [uri:$/examples/(?!\w*\.(gif|jpg)$)] was reported by the 
ISAPI filter as NOT a servlet match for a gif file in the examples context, I 
became suspicious of it being the filter.

Using isapi_redirector2.dll version 2.0.2 on W2K Standard Server SP3, IIS 5.0, 
Tomcat 4.1.18, JDK 1.4.1_01. Non-regex uri mappings work fine.

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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs realm-howto.xml

[glenn]

glenn   2003/01/09 17:31:09

  Modified:webapps/tomcat-docs realm-howto.xml
  Log:
  Add TOC and add listing for DataSourceRealm
  
  Revision  ChangesPath
  1.9   +28 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/realm-howto.xml
  
  Index: realm-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/realm-howto.xml,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- realm-howto.xml   28 Dec 2002 02:04:36 -  1.8
  +++ realm-howto.xml   10 Jan 2003 01:31:09 -  1.9
  @@ -13,6 +13,31 @@
   
   
   
  +
  +
  +
  +Quick Start
  +
  +What is a Realm?
  +Configuring a Realm
  +
  +
  +Standard Realm Implementations
  +
  +JDBCRealm
  +DataSourceRealm
  +JNDIRealm
  +MemoryRealm
  +
  +Common Features
  +
  +Digested Passwords
  +Example Application
  +Manager Application
  +
  +
  +
  +
   
   
   
  @@ -66,6 +91,9 @@
   Three standard plug-ins are provided, supporting connection to three different
   sources of authentication information:
   
  +DataSourceRealm - Accesses authentication
  +information stored in a relational database, accessed via a named JNDI
  +JDBC DataSource.
   JDBCRealm - Accesses authentication information
   stored in a relational database, accessed via a JDBC driver.
   JNDIRealm - Accesses authentication information
  
  
  

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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs tomcat-docs.xsl

[glenn]

glenn   2003/01/09 17:32:53

  Modified:webapps/tomcat-docs tomcat-docs.xsl
  Log:
  Add ability to disable generating left navigation menu
  
  Revision  ChangesPath
  1.9   +8 -5  jakarta-tomcat-4.0/webapps/tomcat-docs/tomcat-docs.xsl
  
  Index: tomcat-docs.xsl
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/tomcat-docs.xsl,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- tomcat-docs.xsl   25 Jan 2002 15:21:51 -  1.8
  +++ tomcat-docs.xsl   10 Jan 2003 01:32:53 -  1.9
  @@ -19,6 +19,7 @@
 
 
 
  +  
   
   
 
  @@ -99,10 +100,12 @@
   
 
   
  -LEFT SIDE NAVIGATION
  -
  -  
  -
  +
  +  LEFT SIDE NAVIGATION
  +  
  +
  +  
  +
   
   RIGHT SIDE MAIN BODY
   
  
  
  

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

DO NOT REPLY [Bug 15941] New: - Expose rootCause exceptions at deeper levels

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15941

Expose rootCause exceptions at deeper levels

   Summary: Expose rootCause exceptions at deeper levels
   Product: Tomcat 4
   Version: Nightly Build
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In bug #15873, the user complains that he cannot get the stack trace
of an exception that occurs within a custom bean invoked via the
JSTL EL Evaluator. He suggests we make the stack trace of the lowest 
level exception available as a string so it can be displayed when this
situation occurs. 

However, it seems more appropriate to have Tomcat improve the way
it handles exceptions.

In the situation exposed in but #15873, there are 3 levels of errors:
   1. exception thrown by the bean (e.g. MyBeanException)
   2. exception thrown by the EL Evaluator (JspException, root cause is
MyBeanException thrown in 1)
   3. exception thrown by the JSP container (ServletException, root cause is 
 JspException in level 2)

Currently, tomcat only displays stack traces for levels 2 and 3. 
It would be great if it could recursively display stack traces for 
root causes of lower levels.

So... Through introspection, one could figure out if a root cause exception
itself has a getRootCause() method that returns a Throwable instance
and if so, displays the stack trace for that root cause; and so on...

This has the potential of creating some very long stack traces, but it could
be argued that the top 2 levels (ServletException and JspException) are useless
when lower level exceptions exist.

Discussed this with Craig McClanahan, who added the following thought:

"One thing we should definitely do, though, is to transparently unwrap 
any InvocationTargetException that occurs.  An example would be a 
 call (executed via reflection) and the property setter 
throws an exception.  This will save one level of stack trace that 
doesn't add any value, and will often lead to uncovering what really 
caused the exception in the first place."

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

DO NOT REPLY [Bug 10026] - manager/stop and manager/remove

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10026

manager/stop and manager/remove





--- Additional Comments From [EMAIL PROTECTED]  2003-01-10 02:32 ---
I can't reproduce this problem with Tomcat 4.1.18. Please let me know if you
are still having problems with this.  If you are, could you please test with
Tomcat 4.1.18 to see if it still exists.

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

DO NOT REPLY [Bug 10508] - NullPointerException on manager/remove after manager/stop

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10508

NullPointerException on manager/remove after manager/stop

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-10 02:50 ---
This works in Tomcat 4.1 without throwing an exception.  This will not be fixed
in Tomcat 4.0.x which is only updated now if there is a security bug which has
to be fixed.

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

DO NOT REPLY [Bug 10508] - NullPointerException on manager/remove after manager/stop

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10508

NullPointerException on manager/remove after manager/stop

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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

Calling into Servlet Container without HTTP

[Kelly Chen]

Hi, there:

I am looking for a way to invoke a Servlet without going through HTTP. I 
understand that this has to be container specific logic, so I would like 
to do this on Tomcat 4.1.18.

The idea is to use JSP as a template system, but JSP has be to run 
inside a Servlet Container. So I would like to be able to invoke JSP 
through Tomcat and get result directly without going through HTTP.

I just wonder if anyone has attempt the similar task  or has some points 
to share.

Thanks.

--
Kelly Chen   Tumbleweed Communication Corp.
T:650-216-2043   700 Saginaw Drive
F:650-216-2565   Redwood City, CA 94063





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

RE: Duplicate session IDs are *common*

[Schnitzer, Jeff]

I've already patched the 4.1.12 version we are running with the fix that
is currently in CVS.  Unfortunately our only notification of when the
problem occurs is when users notice (which they probably wouldn't unless
they acquired an administrative session) and choose to inform us.  I
won't "know" the fix worked without waiting some number of weeks.

One thing to contemplate is that if you have 100,000 sessions and you
get 10 new sessions created every second, that's the equivalent of 1
million inadvertent hack attempts every single second.  Granted that's
still small compared to the total size of a truly randomly generated
128-bit number, but I wouldn't run a banking application on it.

Jeff Schnitzer

-Original Message-
From: Remy Maucherat 
Subject: Re: Duplicate session IDs are *common* 
Date: Thu, 09 Jan 2003 02:57:23 -0800

We have to make sure the problem is real before putting out any
advisory. You should patch the ManagerBase class to the latest version
to see if it helps (compile the latest version, and put it in
$CATALINA_HOME/server/classes/org/apache/catalina/session). A compiled
version is attached to this email if you can't get it easily.

However:
- We did not have any reports before 4.1.18 that the algorithm used was
weak; it was actually believed it was not, and it had been around for a
long time (I do not believe it was touched at all for months).
- A MD5 hash occurs after getting the SecureRandom. This looks like a
mistake, and decreases the quality of the random a lot, but given the
quality of MD5, that shouldn't be noticeable in the real world.
- If collisions *do* actyually happen, then it is a security problem and
the patch to the StandardManager should fix it. However, it would also
indicate that the ids generated can likely be guessed by an attacker, so
we also have to fix the algorithm.

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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionExpirer.java SimpleSessionStore.java

[billbarker]

billbarker2003/01/09 21:39:11

  Modified:src/share/org/apache/tomcat/core ServerSession.java
   src/share/org/apache/tomcat/modules/session
SessionExpirer.java SimpleSessionStore.java
  Log:
  Make certain that a session has been recycled before being reused.
  
  I'm using STATE_INVALID to signal that it is OK to reuse the session (since it is 
currently unused).  It might be better to rename it STATE_RECYCLED.
  
  Fix for bug #15894
  Reported By: Christian Wicke [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.14  +1 -2  
jakarta-tomcat/src/share/org/apache/tomcat/core/ServerSession.java
  
  Index: ServerSession.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ServerSession.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- ServerSession.java1 Sep 2001 00:48:48 -   1.13
  +++ ServerSession.java10 Jan 2003 05:39:11 -  1.14
  @@ -127,7 +127,7 @@
   Context context;
   ContextManager contextM;
   private Object notes[]=new Object[ContextManager.MAX_NOTES];
  -private int state=STATE_NEW;
  +private int state=STATE_INVALID;
   Object facade;
   
   public ServerSession() {
  @@ -287,7 +287,6 @@
facade=null;
attributes.clear();
ts.recycle();
  - id.recycle();
   }
   
   
  
  
  
  1.5   +1 -0  
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionExpirer.java
  
  Index: SessionExpirer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionExpirer.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- SessionExpirer.java   1 Sep 2001 00:52:37 -   1.4
  +++ SessionExpirer.java   10 Jan 2003 05:39:11 -  1.5
  @@ -167,6 +167,7 @@
// After expiring it, we clean up.
if( debug > 0 ) se.log( "Recycling " + sses);
sses.recycle();
  + sses.setState( ServerSession.STATE_INVALID );
}
   }
   }
  
  
  
  1.22  +3 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java
  
  Index: SimpleSessionStore.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- SimpleSessionStore.java   30 Aug 2002 05:41:42 -  1.21
  +++ SimpleSessionStore.java   10 Jan 2003 05:39:11 -  1.22
  @@ -272,13 +272,14 @@
log( "Shuting down " + id );
session.setState( ServerSession.STATE_SUSPEND );
session.setState( ServerSession.STATE_EXPIRED );
  + session.setState( ServerSession.STATE_INVALID );
}
   }
   
   public int sessionState( Request req, ServerSession session, int state ) {
TimeStamp ts=session.getTimeStamp();
   
  - if( state==ServerSession.STATE_EXPIRED ) {
  + if( state==ServerSession.STATE_INVALID ) {
// session moved to expire state - remove all attributes from
// storage
SimpleSessionManager ssm=(SimpleSessionManager)session.getManager();
  @@ -417,6 +418,7 @@
// that's what the original code did
oldS.setState( ServerSession.STATE_EXPIRED );
oldS.recycle();
  + oldS.setState( ServerSession.STATE_INVALID );
}
sessions.put( newId, session );
return (session);
  
  
  

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

cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpSessionFacade.java

[billbarker]

billbarker2003/01/09 21:40:12

  Modified:src/facade22/org/apache/tomcat/facade HttpSessionFacade.java
  Log:
  Add support for the new STATE_INVALID behavior.
  
  Fix for bug #15894
  Reported By: Christian Wicke [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.19  +1 -0  
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java
  
  Index: HttpSessionFacade.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- HttpSessionFacade.java22 Mar 2002 02:54:34 -  1.18
  +++ HttpSessionFacade.java10 Jan 2003 05:40:12 -  1.19
  @@ -155,6 +155,7 @@
if( dL > 0 ) d("Invalidate " + realSession.getId());
realSession.setState(ServerSession.STATE_EXPIRED);
realSession.recycle();
  + realSession.setState(ServerSession.STATE_INVALID);
   }
   
   /**
  
  
  

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

DO NOT REPLY [Bug 15894] - Access to other sessions possible (session is immediately recycled after invalidation/expiration)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15894

Access to other sessions possible (session is immediately recycled after 
invalidation/expiration)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-10 05:43 ---
Fixed now in the CVS, and will appear in the next nightly.

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

Re: Duplicate session IDs are *common*

[Remy Maucherat]

Schnitzer, Jeff wrote:

I've already patched the 4.1.12 version we are running with the fix that
is currently in CVS.  Unfortunately our only notification of when the
problem occurs is when users notice (which they probably wouldn't unless
they acquired an administrative session) and choose to inform us.  I
won't "know" the fix worked without waiting some number of weeks.


You could icrement a variable to list the number of duplicates detected. 
The patch should guarantee uniqueness of the ids, and this is supposed 
to fix the issue.

One thing to contemplate is that if you have 100,000 sessions and you
get 10 new sessions created every second, that's the equivalent of 1
million inadvertent hack attempts every single second.  Granted that's
still small compared to the total size of a truly randomly generated
128-bit number, but I wouldn't run a banking application on it.


In theory, the odds are so small it just cannot happen. I can't 
reproduce an id collision so far.

Remy


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

RE: Duplicate session IDs are *common*

[Costin Manolache]

Schnitzer, Jeff wrote:

> I've already patched the 4.1.12 version we are running with the fix that
> is currently in CVS.  Unfortunately our only notification of when the
> problem occurs is when users notice (which they probably wouldn't unless
> they acquired an administrative session) and choose to inform us.  I
> won't "know" the fix worked without waiting some number of weeks.
> 
> One thing to contemplate is that if you have 100,000 sessions and you
> get 10 new sessions created every second, that's the equivalent of 1
> million inadvertent hack attempts every single second.  Granted that's
> still small compared to the total size of a truly randomly generated
> 128-bit number, but I wouldn't run a banking application on it.

I would check the application too - Craig had a very good point.
Even with java.util.Random it is very unlikely to generate 2 identical 
numbers close enough for 2 current sessions to be swaped.

It's easy to add a log line when a duplicate is detected. One
think is pretty sure - with the patch applied you can't have
duplicated IDs. 

Note that you would need 1 million sessions that are active at the
same time - if a session expires and the id is reused there is no harm.

Costin




> 
> Jeff Schnitzer
> 
> -Original Message-
> From: Remy Maucherat
> Subject: Re: Duplicate session IDs are *common*
> Date: Thu, 09 Jan 2003 02:57:23 -0800
> 
> We have to make sure the problem is real before putting out any
> advisory. You should patch the ManagerBase class to the latest version
> to see if it helps (compile the latest version, and put it in
> $CATALINA_HOME/server/classes/org/apache/catalina/session). A compiled
> version is attached to this email if you can't get it easily.
> 
> However:
> - We did not have any reports before 4.1.18 that the algorithm used was
> weak; it was actually believed it was not, and it had been around for a
> long time (I do not believe it was touched at all for months).
> - A MD5 hash occurs after getting the SecureRandom. This looks like a
> mistake, and decreases the quality of the random a lot, but given the
> quality of MD5, that shouldn't be noticeable in the real world.
> - If collisions *do* actyually happen, then it is a security problem and
> the patch to the StandardManager should fix it. However, it would also
> indicate that the ids generated can likely be guessed by an attacker, so
> we also have to fix the algorithm.



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

DO NOT REPLY [Bug 15944] New: - Compiled JSP page includes default setContentType() Call when not specified in the JSP page.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15944

Compiled JSP page includes default setContentType() Call when not specified in the JSP 
page.

   Summary: Compiled JSP page includes default setContentType() Call
when not specified in the JSP page.
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If the JSP file does not set content type, the following line is automatically 
generated in the compiled .java file:
response.setContentType("text/html;charset=ISO-8859-1");
In cases where the content type is set in the servlet (e.g.: a subclass of 
struts Action class) and the JSP page is forwarded to, this behavior overwrites 
the intended content type with "text/html;charset=ISO-8859-1".

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

DO NOT REPLY [Bug 15944] - Compiled JSP page includes default setContentType() Call when not specified in the JSP page.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15944

Compiled JSP page includes default setContentType() Call when not specified in the JSP 
page.

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|Other   |High

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

DO NOT REPLY [Bug 15944] - Compiled JSP page includes default setContentType() Call when not specified in the JSP page.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15944

Compiled JSP page includes default setContentType() Call when not specified in the JSP 
page.





--- Additional Comments From [EMAIL PROTECTED]  2003-01-10 07:01 ---
I'm using the optional task jspc in ANT 1.5.1 to compile all JSP pages. Right 
now, I have to use the "replace" task to remove the 
line "response.setContentType("text/html;charset=ISO-8859-1");"

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

DO NOT REPLY [Bug 15944] - Compiled JSP page includes default setContentType() Call when not specified in the JSP page.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15944

Compiled JSP page includes default setContentType() Call when not specified in the JSP 
page.





--- Additional Comments From [EMAIL PROTECTED]  2003-01-10 07:13 ---
See also bug #11197.

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

cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt

[billbarker]

billbarker2003/01/09 23:21:38

  Modified:.RELEASE-NOTES-3.3.2.txt
  Log:
  Document fix for 15894
  
  Revision  ChangesPath
  1.16  +3 -1  jakarta-tomcat/RELEASE-NOTES-3.3.2.txt
  
  Index: RELEASE-NOTES-3.3.2.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat/RELEASE-NOTES-3.3.2.txt,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- RELEASE-NOTES-3.3.2.txt   5 Dec 2002 06:51:04 -   1.15
  +++ RELEASE-NOTES-3.3.2.txt   10 Jan 2003 07:21:38 -  1.16
  @@ -65,6 +65,8 @@
   
 Fix the handling of response.encodeURL("") to conform to the w3 spec.
   
  +15894 Fix race condition on reusing Sessions.
  +
   Jasper:
   
   Bug No.  Description
  
  
  

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

DO NOT REPLY [Bug 15946] New: - Documentation change

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15946

Documentation change

   Summary: Documentation change
   Product: Tomcat 4
   Version: Unknown
  Platform: All
   URL: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-
datasource-examples-howto.html
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi, this is my first bug that I am filing for Tomcat, but it's not even a bug. 
I dont know who to contact for a documentation change.

On the following page...

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-datasource-examples-
howto.html

is a DataSource guideline for the Oracle database. There was a comment there 
that had insired me to file this bug: "We would appreciate comments on this 
section as I'm not an Oracle DBA :-)"

I had no success with the suggested configuration that was provided, but after 
long hours of trial, error, and stabbing in the dark, I have found the only 
solution that works.

This is for Oracle9i (probably the same for Oracle8i as well):

server.xml:





factory
oracle.jdbc.pool.OracleDataSourceFactory


driverType
thin


networkProtocol
tcp


serverName
nameOfServerRunningDB


databaseName
putDBNameHere


portNumber
1521


user
putUserHere


password
putPassHere


maxActive
20


maxIdle
10


maxWait
-1




web.xml:


Oracle Datasource example
jdbc/oracledb
oracle.jdbc.pool.OracleDataSource
Container


I hate this configuration as much as anyone else should because of the Oracle 
specific classes having to be used. However, the example code can stay the 
same - which is a plus.

Tomcat is the best :)

Thanks,

Seva

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

How can I modify the 404 Error page, or other java exceptions

[Dan Agarlita]

You can modify the web.xml  directive:

404
/error404.jsp

.

java.lang.Exception
/error500.html


The  tag is contained by  tags.
 
The order of tags in the web.xml is very important.
 
Best regards,
ADan

DO NOT REPLY [Bug 15672] - DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15672

DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver





--- Additional Comments From [EMAIL PROTECTED]  2003-01-10 07:38 ---
I am having this same error with Postgresql with this version.

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

DO NOT REPLY [Bug 15937] New: - Misleading error message produced if jsp:body is not a child of a standard or custom action.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15937

Misleading error message produced if jsp:body is not a child of a standard or custom 
action.

   Summary: Misleading error message produced if jsp:body is not a
child of a standard or custom action.
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The following error is produced when jsp:body is not a child of a custom or
standard action:

   "The action is not a recognizable standard action."

This is misleading as jsp:body is indeed a standard action.

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