DO NOT REPLY [Bug 24563] - Problem with SSL authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24563. 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=24563 Problem with SSL authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-11-22 10:08 --- In the absence of any further comments, I am resolving this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20714] - response charset defaults to iso-8859-1 where java 1.4.2beta ignores file.encoding and use platform default encoding...
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20714. 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=20714 response charset defaults to iso-8859-1 where java 1.4.2beta ignores file.encoding and use platform default encoding... --- Additional Comments From [EMAIL PROTECTED] 2003-11-22 12:53 --- I found a solution email that Remy Maucherat reply in tomcat-user mailing list. I think, someone come to here (Bug Database) may want to read it. http://marc.theaimsgroup.com/?l=tomcat-userm=106916700914797w=2 I don't know why I also found this problem in Tomcat 5.0.14 beta while the coyote revision 1.30 was correct this problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20073] - no object DCH for MIME type text/plain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073.
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=20073
no object DCH for MIME type text/plain
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
OS/Version|Windows NT/2K |Solaris
Platform|Other |Sun
--- Additional Comments From [EMAIL PROTECTED] 2003-11-22 15:20 ---
Hi,
Our client also got the exactly same exception.
Their environment is Tomcat 4.1.12 with:
mail.jar
activation.jar
installed in:
${catalina.home}/shared/lib
Even we placed these JAR files into:
(docBase)/WEB-INF/lib
we still had the same problem.
As you pointed, the implementation of DataContentHandler is available within
activation.jar.
So, I investigated how JavaMail API (Transport class) get DataContentHandler...
According to the Java Doc of Java Activation Framework, DataContentHandler is
available within CommandMap object.
On the CommandMap object, we can query the DataContentHandler object appropriate
for the specified mime-type String.
The code fragment will look like this:
CommandMap cmap=CommandMap.getDefaultCommandMap();
DataContentHandler dch=cmap.createDataContentHandler(text/plain);
The return value of the first line is always MailCapCommandMap.
To create the appropriate DataContentHandler for the given mime-type,
MailCapCommandMap searched the mailcap file in the several places.
According to the Java Doc of Java Activation Framework again, the last place to
be searched is:
META-INF/mailcap.default
that should exist within activation.jar in usual case.
I extracted the activation.jar, but
META-INF/mailcap.default
exists in fact, and its contents also look fine...
The question here is... What prevents this mailcap to be loaded?
The answer on our case is SecurityManager!
If I understand Servlet Spec correctly, the classes marked as Java Extension
should be searched by the parent class-loader at first.
So, when we place activation.jar into:
${catalina.home}/shared/lib
all the classes in Java Activation Framework will be loaded from this JAR file,
even if we place it also in:
(docBase)/WEB-INF/lib
But, with SecurityManager enabled, the classes loaded from:
${catalina.home}/shared/lib/activation.jar
need the read permission for:
${catalina.home}/shared/lib/activation.jar!META-INF/mailcap.default
We updated:
${catalina.home}/conf/catalina.policy
and add:
grant codeBase file:${catalina.home}/shared/lib/activation.jar {
permission java.io.FilePermission /usr/local/tomcat418/shared/lib/-,read;
};
And the problem gone way.
I'm not sure about the details of your environment, but if you run your Tomcat
with SecurityManager, the my solution may help you too.
Any questions are welcome to me.
--
Happy Java programming!
Jun Inamori
OOP-Reserch Corporation
E-mail: [EMAIL PROTECTED]
URL:http://www.oop-reserch.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20073] - no object DCH for MIME type text/plain
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073.
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=20073
no object DCH for MIME type text/plain
--- Additional Comments From [EMAIL PROTECTED] 2003-11-22 21:05 ---
Hi again,
I was somewhat confused in my previous message.
The definition of mime-type and DCH should be:
META-INF/mailcap
in mail.jar, not
META-INF/mailcap.default
in activation.jar.
And the required entity in catalina.policy will look like this:
grant codeBase file:${catalina.home}/shared/lib/activation.jar {
permission java.io.FilePermission
/usr/local/jakarta-tomcat-4.1.12-LE-jdk14/shared/lib/mail.jar,read;
};
Anyway, I re-wrote my message...
-
As you did, our client got the exception like this:
javax.mail.SendFailedException: Sending failed;
nested exception is:
javax.mail.MessagingException: IOException while sending message;
nested exception is:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type
text/plain
at javax.mail.Transport.send0(Transport.java:219)
To re-produce it on our development machine, I tried several configurations.
And only when I start Tomcat with ScurityManager, I got the same one.
DCH is short hand of DataContentHandler, and it is responsible for creating
the binary stream that will be sent to the SMTP server.
Because there are many kinds of mail body, the several implementations are
included in mail.jar.
For example, mail.jar shipped with the DataContentHandler for text/plain and
image/jpeg.
When javax.mail.Transport tries to send the e-mail, it creates the
DataContentHandler implementation appropriate for the mime-type of the out-going
e-mail.
The mapping between the mime-map and the class name of DataContentHandler is
defined by:
META-INF/mailcap
in mail.jar, and this mailcap is read by CommandMap object.
For example, to create DataContentHandler implementation for text/plain, your
code will look like this:
CommandMap cmap=CommandMap.getDefaultCommandMap();
DataContentHandler dch=cmap.createDataContentHandler(text/plain);
Then, CommandMap object reads:
META-INF/mailcap
from mail.jar, and creates the DataContentHandler object for text/plain.
This is what is done by javax.mail.Transport to send the e-mails.
By the way, where CommandMap comes from?
Its fully qualified class name is:
javax.activation.CommandMap
Yes, this class is included in activation.jar.
According to Servlet Spec, the classes marked as Java Extension should be
searched by the parent class-loader at first, rather than by the class-loader
for each web application.
So, when we place activation.jar into:
${catalina.home}/shared/lib
all the classes in Java Activation Framework will be loaded from this JAR file,
even if we place it also in:
(docBase)/WEB-INF/lib
To read:
META-INF/mailcap
from:
${catalina.home}/shared/lib/mail.jar
CommandMap object from:
${catalina.home}/shared/lib/activation.jar
needs the read permission to:
${catalina.home}/shared/lib/mail.jar
To make it possible, catalina.policy should include the entity like:
grant codeBase file:${catalina.home}/shared/lib/activation.jar {
permission java.io.FilePermission
/usr/local/jakarta-tomcat-4.1.12-LE-jdk14/shared/lib/mail.jar,read;
};
In addition, mail.jar in:
${catalina.home}/shared/lib
needs the Socket permission to access the SMTP server.
So, catalina.policy also need the entities like:
grant codeBase file:${catalina.home}/shared/lib/mail.jar {
permission java.net.SocketPermission localhost, connect,resolve;
};
I'm not sure about the details of your environment, but if you run your Tomcat
with SecurityManager, the my solution may help you too.
Any questions are welcome to me.
Best regards,
--
Happy Java programming!
Jun Inamori
OOP-Reserch Corporation
E-mail: [EMAIL PROTECTED]
URL:http://www.oop-reserch.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
catalina.policy to avoid no object DCH for MIME...
Hi,
We faced the same problem as:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg48320.html
The message reports the exception when sending e-mail.
It looks like this:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type
text/plain
at javax.mail.Transport.send0(Transport.java:219)
We re-produce this, only if we enable SecurityManager and place mail.jar and
activation.jar into:
${catalina.home}/shared/lib
SecurityManager seems to prevent javax.activation.CommandMap to load:
META-INF/mailcap
from mail.jar
To avoid this kind of problem, catalina.policy should include the entity like this:
grant codeBase file:${catalina.home}/shared/lib/activation.jar {
permission java.io.FilePermission
/usr/local/jakarta-tomcat-4.1.12-LE-jdk14/shared/lib/mail.jar,read;
};
I request you to add the lines below to catalina.policy.
// If you place mail.jar and activation.jar into:
//${catalina.home}/shared/lib
// please activate the entity below and update the target of
// FilePermission.
//grant codeBase file:${catalina.home}/shared/lib/activation.jar {
// permission java.io.FilePermission
/usr/local/jakarta-tomcat-4.1.12-LE-jdk14/shared/lib/mail.jar,read;
//};
I think this will help many Tomcat users, but do no harm.
Any suggestion/questions are welcome to me.
--
Happy Java programming!
Jun Inamori
OOP-Reserch Corporation
E-mail: [EMAIL PROTECTED]
URL:http://www.oop-reserch.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: SingleSignOn Valve and FormAuthenticator Principal Caching
open a bug, submit your patch to that bug, and someone will get to it :) Filip -Original Message- From: Nelson, Luke [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 2:27 PM To: [EMAIL PROTECTED] Subject: SingleSignOn Valve and FormAuthenticator Principal Caching I believe that I have found a problem with the SingleSignOn valve, and the Principal caching that is performed in the FormAuthenticator. I believe that I have a valid patch for the issue, and I would like to discuss my proposed changes with the community. After reading the community rules, however, I'm unsure whether I'm suppose to present this discussion on the mailing list, or create a new bug report, and have everything tracked there. I believe my patch fixes some interaction problems with JBoss and Tomcat when Tomcat is used as an embedded server (related to bug 23881). Luke Nelson - 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: SingleSignOn Valve and FormAuthenticator Principal Caching
Hi, Your timing is good to bring this up. We should definitely compare notes. Last night I committed a patch to JBoss that deals with this issue (classes can be found in the JBoss CVS in the org.jboss.web.catalina.tc4 package; most are in the authenticator subpackage). The JBoss patch is really more properly a Tomcat patch, but the JBoss folks asked me to commit it. I was planning to post a version to the Tomcat Bugzilla this weekend. In fact, I'll do it (against Bug 23881) as soon as I send this. The TC patch is against TC 5 HEAD; the JBoss version is against TC 4.1, plus has some minor tweaks to optimize for embedding in JBoss. Best, Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 At 04:27 PM 11/21/2003 -0600, you wrote: I believe that I have found a problem with the SingleSignOn valve, and the Principal caching that is performed in the FormAuthenticator. I believe that I have a valid patch for the issue, and I would like to discuss my proposed changes with the community. After reading the community rules, however, I'm unsure whether I'm suppose to present this discussion on the mailing list, or create a new bug report, and have everything tracked there. I believe my patch fixes some interaction problems with JBoss and Tomcat when Tomcat is used as an embedded server (related to bug 23881). Luke Nelson - 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]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. 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=23881 SingleSignOn and FormAuthenticator in embedded tomcat --- Additional Comments From [EMAIL PROTECTED] 2003-11-23 00:01 --- Created an attachment (id=9247) Patch w/ diff and one new class - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881. 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=23881 SingleSignOn and FormAuthenticator in embedded tomcat --- Additional Comments From [EMAIL PROTECTED] 2003-11-23 00:18 --- Attached is a proposed patch. It adds a configurable attribute requiresReauthentication to SingleSignOn. If false (the default), applications will behave as they do now. If true, each incoming request will need to be reauthenticated to the Realm. The various authenticators have been modified to handle this. In this case the SingleSignOnEntry serves as a store of authentication credentials. If the 1st webapp a user visits uses FORM or BASIC auth, and then they visit another app that requires DIGEST, the cached username/password from the FORM/BASIC authentication will not be sufficient information to do a digest authentication, so the user will be prompted for a digest login. Possibly we could add a config option to allow a username/password authentication to override the DIGEST auth specified in the web.xml. Similarly, if the user first visits a webapp with DIGEST auth, and then visits one that uses FORM or BASIC, again the cached credentials will not be sufficient (no cached password from the digest auth), so they will have to be prompted for their username/password. The attached patch includes logic that deals with all this and ensures that a single SSO session is maintained throughout. Of course, if webapps in a deployment don't mix their authentication schemes, none of the above details are an issue. This bug was raised against TC 4; sorry the patch is against TC 5. I can very easily pull together a TC4.1 version if desired. This patch also addresses bug 10040. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10040] - SingleSignOn valve unbounded memory use
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10040. 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=10040 SingleSignOn valve unbounded memory use --- Additional Comments From [EMAIL PROTECTED] 2003-11-23 00:19 --- Please see bug 23881 for a proposed patch that also addresses this bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSP implicit writer (out) vs. response.getWriter()
Hi all, I recently started working with Tomcat (4.1.29) and ran into an inconsistency between the implicit out variable in a JSP and response.getWriter(). Consider this JSP: html body Me first. % response.getWriter().println(Me second); % /body /html I was surprised to discover that the out of this is: Me second. html body Me first. /body /html Looking at org.apache.jasper.runtime.PageContextImpl and JspWriterImpl, it appears that the out variable is set up with its own buffer, which explains why text sent straight to the response writer appears first (before the JSP writer buffer gets flushed). Am I missing something or is this the way it actually works? If I have it straight, is this a bug? I'm not sure about the JSP spec, but other app servers I've tried seem to accumulate text in a single buffer for both out and response.getWriter(). Thanks, Karl Goldstein
