Re: Sorry, no time to cut release
Remy Maucherat [EMAIL PROTECTED] wrote: I updated the dependencies to current builds. FYI. mx4j-2.1.0 seems to bee unpacked to wrong directory (one mx4j-2.1.0 too far), so that the next build pass doesn't find libraries and downloads mx4j-2.1.0 again. /dd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33175] New: - When two or more Content-Type is received, getParameter returns null.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33175.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33175
Summary: When two or more Content-Type is received, getParameter
returns null.
Product: Tomcat 4
Version: 4.1.30
Platform: PC
OS/Version: Windows 2000
Status: NEW
Severity: normal
Priority: P5
Component: Connector:Coyote HTTP/1.1
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
On tomcat 4.1.30 sometime ServletRequest#getParameter() method return null,
though POST is done from the FORM tag of correct HTML.
Content-Typte of HTTP header was the following at this time.
---
POST ...
...
Content-Type: application/x-www-form-urlencoded, application/x-www-form-
urlencoded
...
key=value
---
It thinks this to be a bug of IE but all browsers cannot be replaced.
There cannot be a thing that there are two or more values in Content-Type.
It is possible to deal with this problem by selecting the one value.
If it is possible, I want you to do as follows.
org.apache.coyote.Request.java getContentType() method.
---
public String getContentType() {
contentType();
if ((contentTypeMB == null) || contentTypeMB.isNull())
return null;
// ** FIX FROM **
String orgContentType=contentTypeMB.toString();
java.util.StringTokenizer ts=new java.util.StringTokenizer
(orgContentType,,);
String lastContentType=ts.nextToken();
while(ts.hasMoreTokens()){
lastContentType=ts.nextToken();
}
return lastContentType;
// return contentTypeMB.toString();
// ** FIX TO **
}
---
regards,
Naru Hayashi
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry, no time to cut release
Hey , I have test it and it works for me, but you are right, I have also two mx4j-2.1.0 directories The old MX4j.2.0.1 has no main directory inside the zip, the new one has one. :-) Regards Peter Dominik Drzewiecki schrieb: Remy Maucherat [EMAIL PROTECTED] wrote: I updated the dependencies to current builds. FYI. mx4j-2.1.0 seems to bee unpacked to wrong directory (one mx4j-2.1.0 too far), so that the next build pass doesn't find libraries and downloads mx4j-2.1.0 again. /dd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J2EE Systemarchitekt und Tomcat Experte http://objektpark.de/ http://tomcat.objektpark.org/ http://centaurus.sourceforge.net/ Am Josephsschacht 72, 44879 Bochum, Deutschland Telefon: (49) 234 9413228 Mobil:(49) 175 1660884 E-Mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry, no time to cut release
Dominik Drzewiecki wrote: Remy Maucherat [EMAIL PROTECTED] wrote: I updated the dependencies to current builds. FYI. mx4j-2.1.0 seems to bee unpacked to wrong directory (one mx4j-2.1.0 too far), so that the next build pass doesn't find libraries and downloads mx4j-2.1.0 again. Yes. I don't know why it happens, but I've modified the properties to take care of that. I'll try to clear that up today. Rmy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
P.K. Khandelwal/GRAIN/Noblegroup is out of the office.
I will be out of the office starting 08-01-2005 and will not return until 24-01-2005. For Urgent work contact Caleen on +65.97861915 or Kua on +65.90129924. I will be in India and may be reached on my Singapore mobile +65.96714014 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] jk 1.2.8 Build failure on linux (1 liner)
William A. Rowe, Jr. wrote: I'm finding that @top_builddir@ isn't resolved when I run ./buildconf / ./configure against apache1.3 apxs, so the libtool isn't resolved. The fix is trivial, use the same fixed top_builddir=.. as all the other /native/ directories used. -0: It would be better to set @top_builddir@ correctly in configure. It still confuses me why, when apxs defined the correct cc / ld for apache 1.3, the apache1.3 module is building with libtool (which might be the wrong compiler, linker, etc.) I'll investigate a complete patch later, but this little one should solve the issue for some. Don't remove libtool otherwise I will have problems: +++ [EMAIL PROTECTED]:/opt/SMAWoIS/apache13 /opt/apache21/sbin/apxs -q LIBTOOL /bin/sh /opt/apache21/build/libtool --silent [EMAIL PROTECTED]:/opt/SMAWoIS/apache13 file /opt/apache21/build/libtool /opt/apache21/build/libtool: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped +++ Attached. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry, no time to cut release
Yoav Shapira wrote: Hi, Oh, there's a little signFile script in my home directory (possibly under a bin directory, I don't remember), that does the pgp and md5 signing. It's worth using or at least verifying that you used the same switches, e.g. -r switch on md5sum. No, I had always been using md5 -q. -r seems to append the name of the file to that, and it doesn't seem to be what you've been using (for ex, in 5.5.6). Are you sure ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Status of 5.0.30
Hi all, What's the story behind 5.0.30? Was it ever released? Cheers, Gary [ [EMAIL PROTECTED] ][ I am Red Hat ][ http://inauspicious.org/ ] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 build.xml build.properties.default
remm2005/01/20 04:00:20
Modified:.build.xml build.properties.default
Log:
- Better handling of MX4J downloading.
Revision ChangesPath
1.222 +1 -2 jakarta-tomcat-5/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
retrieving revision 1.221
retrieving revision 1.222
diff -u -r1.221 -r1.222
--- build.xml 8 Jan 2005 11:14:37 - 1.221
+++ build.xml 20 Jan 2005 12:00:20 - 1.222
@@ -1758,10 +1758,9 @@
param name=destfile value=${xml-apis.jar}/
/antcall
-antcall target=downloadzip
+antcall target=downloadgz
param name=sourcefile value=${jmx.loc}/
param name=destfile value=${jmx.jar}/
- param name=destdir value=${jmx.home}/
/antcall
antcall target=downloadzip
1.140 +4 -4 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.139
retrieving revision 1.140
diff -u -r1.139 -r1.140
--- build.properties.default 19 Jan 2005 14:34:38 - 1.139
+++ build.properties.default 20 Jan 2005 12:00:20 - 1.140
@@ -59,7 +59,7 @@
base-struts.loc=http://archive.apache.org/dist/struts
# - Sourceforge files base location -
-base-sf.loc=http://telia.dl.sourceforge.net/sourceforge
+base-sf.loc=http://unc.dl.sourceforge.net/sourceforge
# --
#REQUIRED LIBRARIES
@@ -189,11 +189,11 @@
commons-fileupload.loc=${base-jakarta.loc}/commons/fileupload/binaries/commons-fileupload-1.0.tar.gz
# - Java Management Extensions (JMX), JMX RI 1.2.1 or later or MX4J
2.0.1 or later -
-jmx.home=${base.path}/mx4j-2.1.0/mx4j-2.1.0
+jmx.home=${base.path}/mx4j-2.1.1
jmx.lib=${jmx.home}/lib
jmx.jar=${jmx.lib}/mx4j.jar
jmx-tools.jar=${jmx.lib}/mx4j-tools.jar
-jmx.loc=${base-sf.loc}/mx4j/mx4j-2.1.0.zip
+jmx.loc=${base-sf.loc}/mx4j/mx4j-2.1.1.tar.gz
# - JUnit Unit Test Suite, version 3.7 or later -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sorry, no time to cut release
Yoav Shapira wrote: Hi, Oh, there's a little signFile script in my home directory (possibly under a bin directory, I don't remember), that does the pgp and md5 signing. It's worth using or at least verifying that you used the same switches, e.g. -r switch on md5sum. No, I had always been using md5 -q. -r seems to append the name of the file to that, and it doesn't seem to be what you've been using (for ex, in 5.5.6). Are you sure ? The only thing I'm sure was that my signFile had been consistent and good -- I don't remember the exact switches ;) Checking now, I see you're right, it was just bad memory on my part. Exactly the reason I wrote the script ;) Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33085] - new Host without restarting Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33085. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33085 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 14:45 --- I thought TC5.5 was the developpement version and TC5.0 was the stable version for the servlet 2.4... If it is so, is it possible to fix this problem in TC5.0.30 ? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 14:54 --- (In reply to comment #6) If you want this fixed, submit a patch for it. I'll be glad to evaluate and commit it as needed. As evidenced by the length of time (nearly 2 months) since you submitted this issue, no committers care about it enough to spend time investigating/resolving it. I don't see how commiters are the one that decide in which direction the code evolves, where it is being fixed or not It should be driven by someone, or a group of people, acting as 'drivers', based on how critical are bugs and users requests This is the only way for the apache group to keep users confidence ! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Apache Jakarta Tomcat 5.5.7-alpha Released
The Apache Jakarta Tomcat team is proud to announce the immediate availability of Tomcat 5.5.7-alpha. This build contains numerous bug fixes, documentation updates, and other improvements. Release notes: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/RELEASE-NOTES Please refer to the change log for the list of changes: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi#tomcat-5.5 Sources: http://jakarta.apache.org/site/sourceindex.cgi#tomcat-5.5 The Apache Jakarta Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33143. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 15:53 --- I'm -0.5 on this: I don't want anything to do with a logging implementation. Leave it java.util.logging, log4j, and commons-logging to work things out. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29091] - Non-ascii characters are not handled correctly...
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29091. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29091 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 15:56 --- A few things. One, whether it occurred in an ancient version or not doesn't make much difference. The codebase is substantially different now. Two, a workaround is just that: a solution for fringe cases that may or may not be addressed in the future. It's less likely to be addressed in the future if you're working with a maintenance branch (active develoment is now in Tomcat 5.5). Three, Tomcat 5.5.7 which was just released should have a fix for this. It'd be great if you could test it out and let us know what you think. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31780] - .jspx produce one long line of HTML output
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31780. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31780 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 15:56 --- Not happening, I see. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33143. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 16:08 --- Make sense. I suppose an implementation of java.logging for servers would be its own separate project. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Jakarta Tomcat 5.5.7-alpha Released
Remy Maucherat wrote: The Apache Jakarta Tomcat team is proud to announce the immediate availability of Tomcat 5.5.7-alpha. This build contains numerous bug fixes, documentation updates, and other improvements. Hi, 5.5.7-alpha is on its way to iBiblio. It's already on http://www.apache.org/dist/java-repository/tomcat/jars. I'll be checking if it doesn't break Geronimo and upgrade the version. Anyone who wants to use Tomcat in Maven declare 5.5.7-alpha as dependency. Jacek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33180] New: - JSTL automatic type conversion gives unexpected results
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33180.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33180
Summary: JSTL automatic type conversion gives unexpected results
Product: Tomcat 5
Version: 5.0.26
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
I have a bean with a property of type char. If I do a simple test, such as the
following:
c:if test=${bean.property == 'C'}
I get this error:
javax.servlet.jsp.el.ELException: An exception occured trying to convert String
C to type java.lang.Long
I would think it would convert the char to a String, given the testCondition,
not a Long.
There is a workaround -- creating a variable like this:
c:set var=name value=${bean.property} with the extra space and then using
the fn:trim function.
However, I don't believe the automatic conversion should work this way.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33106] - SSI Processing Enhancements (patch provided)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33106. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33106 --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 19:05 --- Created an attachment (id=14053) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14053action=view) Fixed a null pointer bug if you failed to specify the contentTypes initParam The contentTypes initParam in SSIFilter was supposed to default to text/html if you failed to specify it, but it was generating a null pointer exception due to a misplaced statement. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33182] New: - Session ID inconsistent on include/forward between web applications
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33182. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33182 Summary: Session ID inconsistent on include/forward between web applications Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I have a single ear file with multiple was files deployed on Tomcat. A quick summary is that if I include to another web app, that web app's session id comes back as the session id of the web app originating the request. But if I just load the included page directly I see a different session id. I feel that if each web app is going to have a separate session id, then that id should be consistent no matter how a given page in that app is access (either via include, forward or a standard top level http request) Let's call them /app1 and /app2 I have a page called session.jsp with the following %=session.getId()% I visit /app1/session.jsp and get a sessionid, call it SESSIONID1 Next I visit /app2/session.jsp and get a different session id call it SESSIONID2 Fine, no problems yet. Now, I have a page in /app1 that includes another page from /app2. Call these page /app1/include.jsp and /app2/included.jsp /app1/include.jsp: In /app1 sessionid= %=session.getId% BR % RequestDispatcher d = ... (get other context etc...) d.include(request,response); % -- /app2/included.jsp: In /app2 sessionid=%=session.getId()% When loading /app1/include.jsp both /app1/include.jsp and /app2/included.jsp give me the same sessionid! That's not consistent with the session id I was given when the same browser instance loaded these pages directly. I did this quickly enough so that session invalidation is not the cause. Because these session ids are inconsistent I cannot track per session data beween more than one web app. There is no single key that I can use to uniquely identify a user. Behavior of other app servers: BEA: Gives a separate sessionid per web application. But if I forward/include between web applications I get the sessionid of the application I include to. WAS: Gives the same session id for each web application visted by the same browser. Different session objects, but the same id! ATG Dynamo: Same behavor as WAS. Thanks in advance for your attention. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33182] - Session ID inconsistent on include/forward between web applications
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33182. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33182 --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 19:59 --- We're not going to fix this for the time being, sorry. One of the issues is that I still consider cross context sessions to not be regular sessions, and the spec does not specify this correctly. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33183] New: - jakarta-tomcat-connectors-1.2.8-src.zip missing util directory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33183. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33183 Summary: jakarta-tomcat-connectors-1.2.8-src.zip missing util directory Product: Tomcat 5 Version: Unknown Platform: Sun OS/Version: Solaris Status: NEW Severity: normal Priority: P2 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Trying to compile the 1.2.8 connector distribution: [EMAIL PROTECTED] ant Buildfile: build.xml build: [mkdir] Created dir: /local/src/jakarta-tomcat-connectors-1.2.8-src/build/classes [mkdir] Created dir: /local/src/jakarta-tomcat-connectors-1.2.8-src/dist/lib BUILD FAILED file:/local/src/jakarta-tomcat-connectors-1.2.8-src/build.xml:45: Basedir /local/src/jakarta-tomcat-connectors-1.2.8-src/util does not exist -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33183] - jakarta-tomcat-connectors-1.2.8-src.zip missing util directory
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33183. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33183 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 20:24 --- build.xml is used for building Java side of connectors. See connectors documentation how to build native library. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Postcard
Remy Maucherat wrote: Allistair Crossley wrote: *rotfl* that's not Remy at all! ;) Those viruses are annoying, since I cannot prevent them from reaching the list :( As long as they use a valid subscriber's address, I cannot do anything. I suppose it would be caught by a spam filter though. Rmy Maybe a solution would be to subscribe from an address that uses SPF - apache checks for SPF, so it'll reject it. I don't like SPF for many resons, but it does have its benfits :-) Gmail.com does spf btw. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Postcard
Along these lines (well, somewhat), is it possible to filter Out of office emails that we get on this list? While I have nothing against the fact that many of you end up sharing your vacation plans with all of us, I wouldn't, for example, want to repeatedly remind everyone I'm away when I go on vacation ;-) Unsubscribing while on vacation is one option, but can/should this be handled at the list management level? Return Receipts play similar tricks on those of us on DSN compliant mail servers. -Rahul
Re: Postcard
Rahul P Akolkar wrote: Along these lines (well, somewhat), is it possible to filter Out of office emails that we get on this list? While I have nothing against the fact that many of you end up sharing your vacation plans with all of us, I wouldn't, for example, want to repeatedly remind everyone I'm away when I go on vacation ;-) Unsubscribing while on vacation is one option, but can/should this be handled at the list management level? Return Receipts play similar tricks on those of us on DSN compliant mail servers. I can't speak for the other moderators but I always give people one chance. If I see 2 or more out of office messages from the same user I unsubscribe them. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33182] - Session ID inconsistent on include/forward between web applications
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33182. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33182 --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 23:34 --- Thanks for the response Remy. I understand that this portion of the servlet spec is underspecified so it's not clear what the behavior should be. I did some additional experimentation and there is just no way to share session specific data between web applications on tomcat. As a workaround I attempted to set a session attribute in /app1. When I include from /app2 to /app1 and attempt to access that attribute it's value is null. If I view the attribute by accessing /app1 directly then of course I can see it. This behavior just seems wrong. An application can't expect session attributes just to come and go depending on how a page was accessed. If I can't get a fix to the first issue about session ids, any chance of getting this session data access behavior changed? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33085] - new Host without restarting Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33085. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33085 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 23:39 --- As per http://jakarta.apache.org/tomcat/index.html 5.5.4 is the latest stable TC5 release. 5.5.x is now the focus of development effort. An explanation of the differences between 5.0.x and 5.5.x is also given. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33175] - When two or more Content-Type is received, getParameter returns null.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33175. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33175 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Summary|When two or more Content- |When two or more Content- |Type is received, |Type is received, |getParameter returns null. |getParameter returns null. --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 23:54 --- As you point out, the bug isn't with Tomcat. The content-type header you describe is invalid. Since it isn't a Tomcat but, I do not propose to change the current Tomact behaviour. I recommend that you use a filter to address this issue. It has the added advantage of being container neutral, so it would work with any spec complaint servler container. If you require advice on how to write such a filter, please ask on the tomcat-user mailing list. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28607] - Unable to read Environment entries specified in GlobalNamingResources
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28607. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28607 --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 00:42 --- The following sentence in http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ config/globalresources.html is therefore misleading: With the exception of Environment values, the resources defined in this element are not visible in the per-web-application contexts unless you explicitly link them with ResourceLink elements. In my understanding (not a native english speaker) it implies, that Environment values _are_ visible _without_ explicitly linking them (what is obviosly not true). So imho this is either a bug in the documentation or a bug in the implementation. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33182] - Session ID inconsistent on include/forward between web applications
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33182. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33182 [EMAIL PROTECTED] changed: What|Removed |Added OS/Version|Linux |All Version|5.0.28 |5.5.7 --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 00:43 --- It's not going to be fixed in 5.0.x. Session created with cross context need to be created using the same session id (and you need to use emptySessionPath). I think another added step is required is to look again in the cookie list to see if the session exists. That's the only way. I do not care at all about the problem, and I will not do anything to address it, but OTOH I heard Jan enjoys cross context stuff. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs/config globalresources.xml
remm2005/01/20 15:46:01 Modified:webapps/docs/config globalresources.xml Log: - Remove incorrect statement. Revision ChangesPath 1.5 +1 -3 jakarta-tomcat-catalina/webapps/docs/config/globalresources.xml Index: globalresources.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/globalresources.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- globalresources.xml 1 Sep 2004 22:04:29 - 1.4 +++ globalresources.xml 20 Jan 2005 23:46:01 - 1.5 @@ -24,9 +24,7 @@ This context is distinct from the per-web-application JNDI contexts described in the a href=../jndi-resources-howto.htmlJNDI Resources HOW-TO/a. - With the exception of codestronglt;Environmentgt;/strong/code - values, - the resources defined in this element are strongnot/strong visible in + The resources defined in this element are strongnot/strong visible in the per-web-application contexts unless you explicitly link them with a href=context.html#Resource Linkslt;ResourceLinkgt;/a elements. /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33186] New: - JAASRealm uses WebApp classloader even if useContextClassloader is true
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33186.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33186
Summary: JAASRealm uses WebApp classloader even if
useContextClassloader is true
Product: Tomcat 5
Version: 5.0.28
Platform: Other
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: Catalina:Modules
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
JAASRealm searches the WebApp classloader during authentication even with
useContextClassLoader=true. This is the case in the standard single instance
configuration ($CATALINA_BASE unset) and the multiple-instance configuration
($CATALINA_BASE set and != $CATALINA_HOME). Probably a result of feature
enhancement bug 29406.
Expected behavior is that with useContextClassLoader=true JAAS authentication
uses classes from $CATALINA_HOME/server/lib (and JDBC Driver from
$CATALINA_HOME/common/lib) and WebApp uses classes from
$CATALINA_BASE/webapps/myWebApp/... using its WebApp classloader.
Observed behavior is NoClassDefError during JAAS authentication (Hibernate
trying to load application classes that exist in both $CATALINA_HOME/server/lib
and $CATALINA_BASE/webapps/myWebApp/... ).
Verification #1: Confirmed by debugging the code and inspecting
Thread.currentThread().getContextClassLoader() in code just before
NoClassDefError is thrown (during execution of LoginContex.login() -
LoginContext.invoke() - our JAAS module execution). Classloader identifies
itself as the WebApp class loader and has settings and parents appropriate to
that designation.
Verification #2: The exact same setup works perfectly if we set
useContextClassloader=false.
Verifcation #3: Removing certain classes and jars from webapps/myWebApp fixes
the NoClassDefError and allows login/authentication to proceed with
useContextClassloader=true.
What is puzzling is why the WebApp classloader is unable to load the user class
in the original configuration. It must be in some odd state because with
useContextClassloader=false it has access to exactly the same set of classes
and works.
Setup:
Oracle JDBC drivers (classes12.jar and ojdbc14.jar) in $CATALINA_HOME/common/lib
Custom JAAS module libraries and support (including Hibernate 2.1.7c) in
$CATALINA_HOME/server/lib/oracle-auth.jar
JAVA_OPTS=-Djava.security.auth.login.config=${CATALINA_HOME}/bin/login.conf
login.conf in $CATALINA_HOME/bin
WebApp myWebApp installed as $CATALINA_BASE/webapps/myWebApp.war (auto-exploded
into $CATALINA_BASE/webapps/myWebApp/)
myWebApp.war contains all the classes included in oracle-auth.jar plus JDBC
drivers and additional libraries.
Config files attached.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33186] - JAASRealm uses WebApp classloader even if useContextClassloader is true
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33186. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33186 --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 02:45 --- Created an attachment (id=14057) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14057action=view) Example web.xml for myWebApp to demonstrate the bug -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33186] - JAASRealm uses WebApp classloader even if useContextClassloader is true
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33186. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33186 --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 02:45 --- Created an attachment (id=14058) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14058action=view) Example login.conf to demonstrate the bug -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33186] - JAASRealm uses WebApp classloader even if useContextClassloader is true
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33186. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33186 --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 02:47 --- Created an attachment (id=14059) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14059action=view) Tomcat catalina.properties used to demonstrate the bug This and other Tomcat properties are unmodified/as shipped in Tomcat 5.0.28 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33187] New: - JAASRealm logs passwords in the clear
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33187. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33187 Summary: JAASRealm logs passwords in the clear Product: Tomcat 5 Version: 5.0.28 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Catalina:Modules AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] JAASRealm logs passwords in the clear: 2005-01-20 17:26:51 JAASRealm[Catalina]: Returning username bob 2005-01-20 17:26:51 JAASRealm[Catalina]: Returning password asdf This is a huge security hole. It should require unusual and explicit configuration to get JAASRealm to emit plaintext passwords if it is even allowed at all. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33143. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 03:46 --- Thanks for your interest in this. I'm not sure if I made the problem clear, however. I'm not asking for Tomcat to change the way its own logging works or anything like that. I'm not asking for Tomcat to provide better handlers for the JDK logging system. The problem I'm trying to solve is this. If you have two webapps that both use JDK logging internally, then they both share the same set of Logger instances. This means that if they use the same names for the loggers (which would be the case if they both make use of the same support library, for example) then their log messages get mixed up together. The log messages from the second webapp will be sent to the handlers of the first webapp and vice versa. Note that the code actually doing the logging is probably not even aware that it's running inside a container. This is arguably a (minor) security issue as well, as a rogue webapp can grab references to the loggers used by other webapps and screw with them. Using this replacement LogManager does nothing more than isolate Loggers to the servlet context that creates them, rather than having them global to the entire VM which is the default. It's still up to the webapp to provide appropriate log filters and handlers for what it wants to do. The reason for my request is that, due to the design of the JDK logging system, this can only be addressed by the container. Without this, there's nothing a correctly written webapp can do to prevent other webapps sending their messages to its logs (accidently or otherwise). Now, you can legitamately argue that JDK logging is badly designed and you don't see why Tomcat should have to fix its mistakes. Fair enough. But at the end of the day, correctly written webapps that happen to use JDK logging may not work too well when they're run inside Tomcat. I think my biggest obstacle to getting this in is that 99.% of webapps running inside Tomcat use Log4j. I think I'm the only person in the world who needs this :-) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33143. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 03:53 --- I'd imagine you're not the only one. If it makes you feel better, we on the log4j-dev list have been dealing with this issue for months now, in preparation for log4j 1.3. Of course, there's nothing preventing you from doing your own Tomcat build with your patch, if you haven't already done so. Whether you've done this already or not, another good idea would be to post your issue on the tomcat- user mailing list: maybe you'll get other creative solutions. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 302 redirect issue -- fixed in version 5?
I see this question comes up once a year, but the last post was in 2003 so I am hoping there is now a fix available: When accessing a directory, Tomcat 4.1 shows the welcome file using a 302 redirect instead of forwarding, as it should. This causes problems for search engine indexing. Would version 5 fix this issue? Or do I need to install Apache? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33187] - JAASRealm logs passwords in the clear
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33187. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33187 --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 05:40 --- Is it a security hole? Yes, but only if you specifically turned on debug tracing. This isn't done by default. To your point, it should require unusual and explicit configuration to get JAASRealm to emit plaintext passwords. It DOES require unusual configuration---tracing. Second, the function of the trace is to report what the JAASCallbackHandler passes back to the LoginModule, and only in a debug/trace scenario. This is very handy for troubleshooting JAAS login modules, which frequently access enterprise resources. If the realm has password digesting turned on, it will log the digest value. It sounds like you don't use digesting in your LoginModule; maybe you should! I'd say the hole isn't huge, but if this is really a problem, simply snipping this line out of JAASCalbackHandler#handle() would fix the issue: if (realm.getContainer().getLogger().isTraceEnabled()) realm.getContainer().getLogger().trace(sm.getString(jaasCallback.password, password)); -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33187] - JAASRealm logs passwords in the clear
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33187. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33187 --- Additional Comments From [EMAIL PROTECTED] 2005-01-21 06:41 --- Tomcat bills itself as a very secure system. (see Tomcat's security record is impeccable at http://jakarta.apache.org/tomcat/faq/security.html ) Exposure of passwords in plain text is something not even MS Windows would allow. Setting the log to a DEBUG level is not uncommon or unusual. It happens all the time. I don't know exactly how the JAAS properties are set or what the sm in the code in question refers to, but I can generally propose a separate JAASRealm property tracePasswords which defaults to false and a change to the code in question to something like: if (realm.getContainer().getLogger().isTraceEnabled()) realm.getContainer().getLogger().trace( tracePasswords ? sm.getString(jaasCallback.password,password) : suppressed, set jaasCallaback.tracePassword=true to show)); For the record, JAAS Password digests, while better than plain text, are vulnerable to dictionary attacks and thus not particulary secure. Exposing them in the logs would still be a security risk. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
important document
Please read the attached file! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33187] - JAASRealm logs passwords in the clear
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33187.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33187
--- Additional Comments From [EMAIL PROTECTED] 2005-01-21 07:18 ---
I think it would be better simply to snip the offending logging lines entirely.
If somebody needs to
debug a LoginModule password issue, it could be done inside the LoginModule as
a hack (since it's
probably a custom code module anyway) instead of in the callback handler. A
quick skim of the JDBC
and JNDI realm implementations shows that those classes don't log passwords, so
JAASRealm probably
shouldn't either.
Therefore, there is a second line---in the class constructor for
JAASCallbackHandler---that should also
be snipped:
if (log.isDebugEnabled()) {
log.debug(sm.getString(jaasCallback.digestpassword, password,
this.password));
}
As for the claim that Tomcat's security record is impeccable --- well, I
don't know who wrote that
text. It is a foolish thing to boast publicly, IMO. Tomcat's record is pretty
good, just not impeccable.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
