war file loading and logging in TC 3.2.1
Hello. I'm using an EmbededTomcat in a project and I'm wondering why I can't specify a war file in the method addContext(String, URL). I want to specify a war file to load up but I can't do that. I must specify the root directory of my webapp. Anybody have an idea? How are the war files loaded up in tomcat standalone? when you put a war file in the webapps directory under the tomcat root they load up just fine. I'm curious to know what the trick is behind that. Another issue is the logging. Does anyone know if I can create a logger with a method call in EmbededTomcat just like the standalone Tomcat can use server.xml to specify loggers. I would want the three standard loggers that are specified in server.xml. I would also like to know (if someone can tell me) the differences between Tomcat 3.2 and Tomcat 3.3 (if I'm allowed to call it that... what was it... the "proposed" Tomcat 3.3?) will be with regards to EmbededTomcat. Are there any major differences that might result in TC 3.3 not working in my server app? Has the interface been changed? If someone can answer this with regards to TC 4 that would be great too. Finally I'm wondering if anyone knows why the SecurityManager in Tomcat 3.2 doesn't allow me to do anything when I start up my EmbededTomcat. I had to create a new policy file which allows anything to do everything. This is not a critical issue I guess, I just think the way I'm doing things are kindof ugly... I'd like to see EmbededTomcat be able to do everything the regular Tomcat can do without having to specify some dummy policy file. Kind regards, Stefan Freyr. Stefan Freyr Stefansson Software Developer deCODE Genetics, Inc. http://www.decode.com Phone: (+354) 570 2854 GSM: (+354) 861 1718 Fax: (+354) 491 3782 Stefan Stefansson.vcf BEGIN:VCARD VERSION:2.1 N;ENCODING=QUOTED-PRINTABLE:;=01 REV:20001030T115142Z END:VCARD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: make jsse support optional
What do you mean by 'as long as jsse is not free'? I've never had to pay for it... to my best knowledge it _is_ free. Regards, Stefan. -Original Message- From: Guillaume Rousse [mailto:[EMAIL PROTECTED]] Sent: 27. febrar 2001 14:00 To: [EMAIL PROTECTED] Subject: make jsse support optional I could be wrong here, as i didn't try to hack the build script, but jsse is currently mandatory for building tomcat, even if ssl support is not used thereafter. As long as jsse is not free, i think it should be rendered optional for building as well. This way, tomcat introduction would be a lot easier for strict licensing policy Linux distributions, such as Debian or Mandrake. Would this wish be acceptable for next Tomcat release ? Guillaume -- After designing a useful routine that gets around a familiar "bug" in the system, the system is revised, the "bug" is taken away, and you're left with a useless routine -- Thoreau's Theories of Adaption n2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: TOMCAT ENCRYPTION OF CREDIT CARD NUMS???????
The only thing you probably need to do is make sure nobody can look at the credit card information while it's being sent from the client to the server. Regular HTTP is text based so everything going over the wire can actually be read by a person, that person could be mr. Evil Man and he could therefore see the credit card number in plain text. So what you would need to do is encrypt the credit card number before it leaves the client browser. The only (IMHO) decent way of doing this is to set up an SSL connection with the client. What that means is you encrypt everything that's going from the client and the server. This is done by setting the webserver up to support SSL (HTTP over SSL is called HTTPS and all urls begin with https://yadiyadiya.bla). I can't really give you much more information about how you would set that up since I'm not very familiar with how to set up parts of websites with https and other parts with http. I could tell you how to encrypt all connections coming in to your website but that is probably a big overhead since you probably don't need to encrypt everything the user does on the web (what he/she puts in his/her shopping cart or whatever) but just need to encrypt the credit card number. You can find info on Tomcat SSL in http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/tomcat-ssl-howto .html. Now if you need to store the credit card encrypted in a database once the server receives it then you should look at: http://www.javasoft.com/products/jce/index.html The recommended encrypt/decrypt algorithm would be an algorithm called Tripple DES and you should probably be able to find something about it somewhere on that site. Look at the API docs and especially at the javax.crypto.Cipher class. Hope this helps at all. Regards, Stefan p.s. it would be interesting to know exactly what you were meaning though... do you need to encrypt the card number to store it in a database or do you just need to encrypt the communication between client/server? -Original Message- From: Mary McCarthy [mailto:[EMAIL PROTECTED]] Sent: 17. janar 2001 02:35 To: [EMAIL PROTECTED] Subject: TOMCAT ENCRYPTION OF CREDIT CARD NUMS??? Hi all, Help badly needed by anyone with ANY information on the foollowing: I am designing an online booking system using JSP, Java Beans and Tomcat for a project at uni. Does anyone have any information on how to encrypt a credit card number with Tomcat in mind. Surely there is some code I code take from somewhere to help me. Credit card security is a side project on top of my booking system. If anyone knows of any documentation or code available on the web, please mail me as all I can seeem to find is companys offering to selll me their security systems for $500! A big thanks in advance!! _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[BUG] Security violation in Tomcat 3.2.1 (was: [BUG] problems with downloading a file, previous JSP gets buffered and sent instead)
Sorry for the repost guys but I think this is serious enough for at
least one reply!
In short, Tomcat is sending me a jsp file... that is to say, it's
sending me the "unprocessed" version of the JSP file, with code and
everything. The JSP file seems to get stuck in the OutputStream buffer
of the response. I don't understand that... what is an unprocessed JSP
file doing in the response buffer anyways?
Please respond,
Stefan Freyr
p.s. I'll file a bug report on this later today unless somebody sees
anything wrong with it.
-Original Message-----
From: Stefán F. Stefánsson
Sent: 4. janúar 2001 10:31
To: Tomcat-Dev
Subject: [BUG] problems with downloading a file, previous JSP gets
buffered and sent instead
Hi.
This sure looks like some kind of bug to me but I can't really say what
exactly is going on.
I have a servlet that gets a file out of a database according to a file
ID. This servlet works just fine when I call it directly (that is, when
I manually write the URL into the address field in my browser). But
then I started to try to call that URL from a link in a JSP page. This
JSP page constructs a list of files available in an inbox and the files
that have not been downloaded are displayed as a link so that the user
can click it and get the file. The link is formed exactly the same way
as the link I used to type in to the address field before (which worked
so well) but this time the FileDownloadServlet tries to send me the
mailbox.jsp file which is the file I call the link from. The only thing
I can do is select "open file" in the dialog box and then it displays
the dialog box again with the file I wanted to download to begin with.
I think the reason for this is that the mailbox.jsp file is still being
stored in some buffer. I wrote out the size of the buffer in the
servlet response in the FileDownloadServlet. Before I wrote anything
into the output stream of the response the Buffer contained 8152 bytes
of data. I tried to flush the stream and reset it but nothing works.
Well... resetting the buffer kindof works... but then I loose the header
I set in the FileDownloadServlet and the file shows up on the screen
which is absolutely not what I want! I want to get the open/save file
dialog box. I got that working by adding these two lines to the servlet
code:
response.setContentType("application/octet; name=" + fileName);
response.setHeader("Content-Disposition", "attachment;
filename=" +
fileName);
No matter whether I put response.flushBuffer() and/or response.reset()
before or after these two lines I always end up with some sort of
problem.
Just to clarify things, I'm attaching a flow diagram to the message so
that those willing to help can understand what the user does before this
happens.
bufferproblem.gif
Any help would be greatly appreciated. Anybody know why the file
mailbox.jsp is stuck in the buffer???
Kind regards,
Stefan Freyr
p.s. depending on the responses to this letter I'll decide if it's
worthy of a bug report. It sure seems to me that the mailbox.jsp file
should not be in the buffer.
Stefan Freyr Stefansson
Software Developer
deCODE Genetics, Inc.
http://www.decode.com
Phone: (+354) 570 2854
GSM: (+354) 861 1718
Fax: (+354) 491 3782
Stefan Stefansson.vcf
bufferproblem.gif
BEGIN:VCARD
VERSION:2.1
N;ENCODING=QUOTED-PRINTABLE:;=01
REV:20001030T115142Z
END:VCARD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
[BUG] problems with downloading a file, previous JSP gets buffered and sent instead
Hi.
This sure looks like some kind of bug to me but I can't really say what
exactly is going on.
I have a servlet that gets a file out of a database according to a file
ID. This servlet works just fine when I call it directly (that is, when
I manually write the URL into the address field in my browser). But
then I started to try to call that URL from a link in a JSP page. This
JSP page constructs a list of files available in an inbox and the files
that have not been downloaded are displayed as a link so that the user
can click it and get the file. The link is formed exactly the same way
as the link I used to type in to the address field before (which worked
so well) but this time the FileDownloadServlet tries to send me the
mailbox.jsp file which is the file I call the link from. The only thing
I can do is select "open file" in the dialog box and then it displays
the dialog box again with the file I wanted to download to begin with.
I think the reason for this is that the mailbox.jsp file is still being
stored in some buffer. I wrote out the size of the buffer in the
servlet response in the FileDownloadServlet. Before I wrote anything
into the output stream of the response the Buffer contained 8152 bytes
of data. I tried to flush the stream and reset it but nothing works.
Well... resetting the buffer kindof works... but then I loose the header
I set in the FileDownloadServlet and the file shows up on the screen
which is absolutely not what I want! I want to get the open/save file
dialog box. I got that working by adding these two lines to the servlet
code:
response.setContentType("application/octet; name=" + fileName);
response.setHeader("Content-Disposition", "attachment;
filename=" +
fileName);
No matter whether I put response.flushBuffer() and/or response.reset()
before or after these two lines I always end up with some sort of
problem.
Just to clarify things, I'm attaching a flow diagram to the message so
that those willing to help can understand what the user does before this
happens.
bufferproblem.gif
Any help would be greatly appreciated. Anybody know why the file
mailbox.jsp is stuck in the buffer???
Kind regards,
Stefan Freyr
p.s. depending on the responses to this letter I'll decide if it's
worthy of a bug report. It sure seems to me that the mailbox.jsp file
should not be in the buffer.
Stefan Freyr Stefansson
Software Developer
deCODE Genetics, Inc.
http://www.decode.com
Phone: (+354) 570 2854
GSM: (+354) 861 1718
Fax: (+354) 491 3782
Stefan Stefansson.vcf
bufferproblem.gif
BEGIN:VCARD
VERSION:2.1
N;ENCODING=QUOTED-PRINTABLE:;=01
REV:20001030T115142Z
END:VCARD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: stupid question on array return by javax.servlet.request.X509Certificateattribute
The idea (I think) is to have the certificate chain in there. Your client certificate is signed by some authority which may, in turn, be signed by someone else and so on... So you could get your client certificate as the first element, the one who signed his certificate as the second and so on. Regards, Stefan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 18. desember 2000 16:16 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: stupid question on array return by javax.servlet.request.X509Certificateattribute Why the attribute 'javax.servlet.request.X509Certificate' return an array of X509Certificate. I don't understand how it's possible because when my client choose an certificate, he chooses only one... For my test array contain always one element... so is it an specification to anticipate the future ? Best Regards The type is javax.servlet.request.X509Certificate[] ?? ie an array not a single instance.. [EMAIL PROTECTED] on 18/12/2000 05:03:48 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Ken X Horn) Subject: RE:RE: Réf. : RE: X509 client certificate (Mr. McClanahan, please take a look at this) Excuse for my determination but my problem was not solve... After change my serveur.xml to clientAuth="true" like Craig R. McClanahan said, I fall again on my first exception when I try to extract the certificate request because object associate with ùrequest attributes nameés 'javax.servlet.request.X509Certificate' aren't of well-known type java.security.cert.X509Certificate but [Ljava.security.cert.X509Certificate;@13a66f ! My snoop servlet give me this fragment information : Request attributes: filters.ExampleFilter.SERVLET_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Servlet Mapped Filter, filterClass=filters.ExampleFilter]) javax.servlet.request.key-size = 40 javax.servlet.request.X509Certificate = [Ljava.security.cert.X509Certificate;@13a66f filters.ExampleFilter.PATH_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Path Mapped Filter, filterClass=filters.ExampleFilter]) javax.servlet.request.cipher-suite = SSL_RSA_EXPORT_WITH_RC4_40_MD5 and my catalina server crash on exception when I try to cast this strange objet to java.security.cert.X509Certificate Exception dans le traitement de la requête sécurisée : java.lang.ClassCastException: [Ljava.security.cert.X509Certificate; at SnoopServlet.doGet(SnoopServlet.java:68) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp. ... Any idea? Best regards Jérôme Jérôme
Differerences in Jakarta distributions (Was 3.2.1 build fails - any ideas?) Please comment
Thanks everybody! I've managed to build it now. The problem was kindof weird and the "solution" (if I can call it a solution) was even weirder... Like one of you pointed out I had to do a "build clean". After that everything worked. I found this rather weird since I deleted EVERYTHING in my Jakarta folder! I even deleted ant and rebuilt it but still this problem occurred. After the "build clean" though... everything worked. So I feel very stupid now if that makes anybody feel any better ;o) But nobody has answered my comment and so I post it again: I think there is a really big need for cleaning up the way Jakarta projects are distributed. There are differences between projects and even within projects (like the root directory for tomcat 3.2 suddenly changed from "tomcat-3.2" to "tomcat-3.2-bX" I think that happened with the beta 7) For example: 1) Tomcat and servletapi come in a zip file that includes the root directory for that project... that is, "jakarta-tomcat-3.2-src" and "jakarta-servletapi-3.2-src" were included in the zip file and the files are ready to be unzipped into the JAKARTA-HOME directory on the user machine (well... almost... more on that in point 2.). However, when I downloaded Ant 1.2 that project came in a zip file that was structured in a different way, specifically, it didnt' include the project root directory so I had to make the jakarta-ant directory myself and unzip the files into that directory. 2) When I had unzipped all files into the JAKARTA-HOME directory I had a structure that looked something like this: JAKARTA HOME jakarta-ant jakarta-servletapi-3.2-src jakarta-tomcat-3.2-src I built ant and servletapi but when I tried building tomcat I found out that it was trying to point to the servletapi.jar in a directory that was supposed to be called jakarta-servletapi but not jakarta-servletapi-3.2-src like my structure was then. Kind regards, Stefan Freyr.
RE: Réf. : RE: X509 client certificate (Mr. McClanahan, please take a look at this)
well... I'm stomped... I think this one is a question for Craig! As I
said, I'm not familiar with the TC 4.0 source.
Do you have any idea why javax.servlet.request.X509Certificate is not
showing up in the Attribute list?
Regards, Stefan.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 15. desember 2000 14:30
To: [EMAIL PROTECTED]
Cc: Stefán F. Stefánsson
Subject: Réf. : RE: X509 client certificate
hello stefan,
I prefere having two answer than any, so thank you for you help but...
when I try with tomcat 4.0-m5 to sniffe my https request, I obtain this
Request attributes :
Request attributes:
filters.ExampleFilter.SERVLET_MAPPED =
InvokerFilter(ApplicationFilterConfig[name=Servlet Mapped Filter,
filterClass=filters.ExampleFilter])
javax.servlet.request.key-size = 40
filters.ExampleFilter.PATH_MAPPED =
InvokerFilter(ApplicationFilterConfig[name=Path Mapped Filter,
filterClass=filters.ExampleFilter])
javax.servlet.request.cipher-suite = SSL_RSA_EXPORT_WITH_RC4_40_MD5
...
Request Is Secure: true
Obviously when I try to extract the
javax.servlet.request.X509Certificate object with this command :
(java.security.cert.X509Certificate)request.getAttribute(
"javax.servlet.request.X509Certificate" ) I obtain an null object.
Any another idea ?
Best regards
Jérôme
Stefán F. Stefánsson [EMAIL PROTECTED]
14/12/00 09:58
Pour :[EMAIL PROTECTED]
cc :
Objet :RE: X509 client certificate
woops... Seems like your mail has already been answered by Craig.
As he said... you aparantly need to upgrade to TC 4.0 m4 at least.
Regards, Stefan Freyr.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 13. desember 2000 15:30
To: Stefán F. Stefánsson
Subject: RE: X509 client certificate
Hi Stefan
I try to extract certicate to my request like you say in your mail but I
have
an exception because object return by request.getAttribute(
"javax.servlet.request.X509Certificate" )
method wasn't type of java.security.cert.X509Certificate but
[Ljava.security.cert.X509Certificate;
log file :
2000-12-13 16:21:10
StandardWrapperValve[org.apache.catalina.INVOKER.SnoopServlet]:
Servlet.service() for servlet org.apache.catalina.INVOKER.SnoopServlet
threw exception
java.lang.ClassCastException: [Ljava.security.cert.X509Certificate;
at SnoopServlet.doGet(SnoopServlet.java:65)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterWrapper.doFilter(ApplicationFi
lterWrapper.java:159)
at filters.ExampleFilter.doFilter(ExampleFilter.java:136)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:258)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:936)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:160)
at
org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticator
Base.java:311)
at
org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja
va:152)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:934)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:167
4)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:161)
at
org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:343
)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:934)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:159)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:936)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.j
ava:787)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:
904)
at java.lang.Thread.run(Thread.java:484)
Very strange but are you an idea about the problem?
Config : Apache Tomcat (v4.0-m1)
Best regards
Jérôme Camilleri
Bull
France
You wrote :
Hi Alexandre.
I'm not sure I fully understand your question but let me see if I can
help you at all.
The addSecureEndpoint method of EmbededTomcat used to be just like the
one you described below. I added the addSecureEndpoint(int port,
InetAddress addr, String hostname, String keyfile, String keypass,
boolean clientAuth) to be able to force the client to show a certificate
for logging in.
I want to answer you in a few steps, so please bear with me.
1.
Now, first of all I think you're going a little bit too long of a way
using t
RE: X509 client certificate
Hi Alexandre.
I'm not sure I fully understand your question but let me see if I can
help you at all.
The addSecureEndpoint method of EmbededTomcat used to be just like the
one you described below. I added the addSecureEndpoint(int port,
InetAddress addr, String hostname, String keyfile, String keypass,
boolean clientAuth) to be able to force the client to show a certificate
for logging in.
I want to answer you in a few steps, so please bear with me.
1.
Now, first of all I think you're going a little bit too long of a way
using the addSecureEndpoint. Wouldn't it be easier for you to call the
method I described above (the addSecureEndpoint(int, InetAddress,
String, String, String, boolean)) instead of calling the original one
(the addSecureEndpoint(int, InetAddress, String, String, String)) and
changing the code in that? The modifications to the original
addSecureEndpoint were for backwards compatability. In other words, the
original method, addSecureEndpoint added an endpoint with no client
authentication. I added a method that provides means for getting client
authentication by the means of client certificates, and modified the
original call to call my method with client authentication == false.
Hence, maintaining backwards compatability. I would say you should much
rather change the code in tomcat to what it was before and call
addSecureEndpoint(int, InetAddress, String, String, String, boolean) in
EmbededTomcat directly instead. That way you won't have to recompile
Tomcat every time you change your mind about requiring a client
certificate in your application.
2.
Now for your problem at hand ;o). I don't know exactly how the
getUserPrincipal method in HttpServletRequest class is supposed to work
but what I got from JavaDoc was:
Returns a java.security.Principal object containing the name of the
current authenticated user. If the user has not been authenticated, the
method returns null.
And from the JavaDoc for java.security.Principal, I got:
This interface represents the abstract notion of a principal, which can
be used to represent any entity, such as an individual, a corporation,
and a login id.
Now. You would think that Tomcat should serve up the DN of the client
certificate when a user calls request.getUserPrincipal but according to
you, it doesn't. I don't know if there are any reasons for that
although I doubt it. I would think this is an oversight and should
prefferably be fixed. That shouldn't be too much trouble. The
ServletAPI Specs are not all that clear about this issue. I would think
that getUserPrincipal works for other types of authentication (the
username, password type). I'll file in a bug report on this matter
after I finish this ;o)
Now for your solution. What you can do is call the method
request.getAttribute( "javax.servlet.request.X509Certificate" ). This
will return a java.security.cert.X509Certificate with all the
information you could possibly want (well... almost) on your client.
This include the distinguished name of the client by using
java.security.cert.X509Certificate.getSubjectDN().
I hope this helps!
Regards, Stefan.
-Original Message-
From: Alexandre A. Drummond Barroso
[mailto:[EMAIL PROTECTED]]
Sent: 3. desember 2000 00:16
To: [EMAIL PROTECTED]
Subject: X509 client certificate
I tried to make Tomcat
changing the following parameter of addSecureEndpoint in
src/share/org/apache/tomcat/startup/EmbededTomcat.java:
public void addSecureEndpoint( int port, InetAddress addr, String
hostname,
String keyFile, String keyPass )
{
addSecureEndpoint(port, addr, hostname, keyFile, keyPass,
false);
^
to true, but when I called request.getUserPrincipal() it just returned
null. Is there any problem with addSecureEndpoint
implementation or in some method it calls?
Regards,
Alexandre
RE: BugRat Report #516 has been filed.
woops... this bug should not have that severity or priority... I didn't notice any place where I should have set that now that I think of it... hmmm... weird... maybe it's a bug in the bug-tracking system? -Original Message- From: BugRat Mail System [mailto:[EMAIL PROTECTED]] Sent: 4. desember 2000 15:12 To: [EMAIL PROTECTED] Subject: BugRat Report #516 has been filed. Bug report #516 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/516 REPORT #516 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2 JVM Release: 1.3 Operating System: Windows 2000 OS Release: 5.00.2195 w/SP1 Platform: Intel x86 Synopsis: request.getUserPrincipal() doesn't work when user is authenticated with a X509 client certificate. Description: Shouldn't this method return the subject DN of the clients X509 certificate?
[BUG] setDebug in EmbededTomcat
This is probably one of the strangest things I've seen so far! I'm working with EmbededTomcat and I have integrated it into our server application. I wanted to get some more information about what the web server was doing so I changed the setDebug(0) to setDebug(10). This resulted in me not finding any jsp or html pages in the web application I had in the root context (I only have one web app so I can't say for sure if this does happen somewhere else). As soon as I set the setDebug back to setDebug(0) I found the pages. This is the case for all debug levels not equal to 0. The weird thing is that it found a servlet I have. I have a controller servlet that handles all requests coming in and I have it forward requests to the correct pages. When I tried to forward to a JSP with debug set to 0 it couldn't find the page although the code in the servlet was being executed. When debug level is set to 10 I got the following error on the console (when running the servlet and forwarding the request to a JSP): ContextManager: Error reading request R( /) 400 Ctx( ): 400 R( /) null Ctx( ): Handler null null Ctx( ): IOException in: R( /) Socket closed Ctx( ): Error: exception inside exception servlet 400 null ContextManager: ProcessRequest: R( /servlet/com.decode.ips.webclient.controller.IPSControllerServlet) ContextManager: After processing: R( + /servlet/com.decode.ips.webclient.controller.IPSControllerServlet + null) Ctx( ): 404 R( + /servlet/com.decode.ips.webclient.controller.IPSControllerServlet + null) null Ctx( ): Handler tomcat.notFoundHandler(null/null) tomcat.notFoundHandler Ctx( ): Error: exception inside exception servlet 404 null Ctx( ): Error: exception inside exception servlet 404 class java.lang.NullPointerException This is weird but I guess it's not critical. The problem with this bug is that the solution (to change setDebug to 0) is not at all obvious. So people who get this kind of problems may have a very hard time figuring out what is wrong. Well... I'll let you guys decide what to do about this... until then I'll just use setDebug(0) :o) Kind regards, Stefan Freyr. p.s. Is the bug system still down? I think it is, that's why I'm not posting it there... let me know if I should do that (when it's up). Stefan Freyr Stefansson Software Developer deCODE Genetics, Inc. http://www.decode.com Phone: (+354) 570 2854 GSM: (+354) 861 1718 Fax: (+354) 491 3782 Stefan Stefansson.vcf BEGIN:VCARD VERSION:2.1 N;ENCODING=QUOTED-PRINTABLE:;=01 REV:20001030T115142Z END:VCARD
RE: ENCTYPE=multipart/form-data
what does your form tag (in HTML) look like? -Original Message- From: Falcon cheetah [mailto:[EMAIL PROTECTED]] Sent: 27. nóvember 2000 07:19 To: [EMAIL PROTECTED] Subject: ENCTYPE="multipart/form-data" I am trying to load a file to my server, in order to use it as an attachment for a JavaMail webmail. I am using an example, which works fine by itself till I start to use it in my application. I am using a form that specifies the encryption type to ENCTYPE="multipart/form-data" which seems like something tomcat does not like! If I remove this line from my form I do not get the attached error, but nothing seems to work. What am I doing wrong here? Please tell me how to ask a user to choose a file to be attached to his email and what is the best way to uploaed it. I am using a couple of examples that really work. But not for tomcat. I am running tomcat 2.3.8 with apache1.3.14 on rd6.1. Error Log - No file was attached! try again! HTTP/1.1 200 OK Date: Mon, 27 Nov 2000 07:02:05 GMT Server: Apache/1.3.14 (Unix) mod_jk Connection: close Content-Type: text/html; charset=iso-8859-1 OK The server encountered an internal error or misconfiguration and was unable to complete your request. __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Tomcat 3.2 b7 build broken???
It can't be that... must be something on my side... but I keep getting the following error when I try to run build (doesn't matter if I do build or build dist). C:\jakarta\jakarta-tomcatbuild Buildfile: build.xml BUILD FAILED build.xml:33: Could not create task of type: copy because I can't find it in the list of task class definitions Anybody have a clue??? Also... why is b7 being distributed under the "jakarta-tomcat-b7-src" folder? Why not just the regular "jakarta-tomcat" folder? What I've done is that I've copied all the stuff from the "jakarta-tomcat-b7-src" folder to the regular "jakarta-tomcat" folder and I'm trying to build it from there. 3.2b6 worked like a charm! Kind regards, Stefan Stefan Freyr Stefansson Software Developer deCODE Genetics, Inc. Phone: (+354) 570 2854 GSM: (+354) 861 1718 Fax: (+354) 491 3782 Stefan Stefansson.vcf BEGIN:VCARD VERSION:2.1 N;ENCODING=QUOTED-PRINTABLE:;=01 REV:20001030T115142Z END:VCARD
[PATCH] Bug 404 - EmbededTomcat and PoolTcpConnector
Here is a patch for bug report 404. It's about the addSecureEndpoint method not working. EmbededTomcat.diff PoolTcpConnector.diff Stefan Freyr Stefansson Software Developer deCODE Genetics, Inc. Phone: (+354) 570 2854 GSM: (+354) 861 1718 Fax: (+354) 491 3782 Stefan Stefansson.vcf EmbededTomcat.diff PoolTcpConnector.diff BEGIN:VCARD VERSION:2.1 N;ENCODING=QUOTED-PRINTABLE:;=01 REV:20001030T115142Z END:VCARD
[PATCH] EmbededTomcat.java and PoolTcpConnector.java
Hi. I've added one method to the EmbededTomcat and that is addCustomEndpoint. This method makes it possible to add an endpoint with a specific ServerSocketFactory. This is very handy when you are trying to integrate Tomcat into applications which have their own socket factory. For example, in our case we have a SocketFactory handed to tomcat that includes a ACL. There are two ways of connecting to the application, through client software or through the web. In either case you have to send a certificate to the server in order to authenticate yourself. By using addCustomEndpoint we can use the same SocketFactory for both connection methods. I've also added an overloaded version of addSecureEndpoint. This method takes one additional parameter which is the string clientauth. This specifies if client authentication is needed. The reason for this being a string is so that multiple levels of authentication are supported as opposed to true or false. In the case of the org.apache.tomcat.net.SSLSocketFactory the only acceptable values are "true" or "false" but other implementations of the ServerSocketFactory class may need various levels of client authentication. Of course this is all backwards compatible. I hope this will be included in the final release of Tomcat 3.2. Kind regards, Stefan Freyr EmbededTomcat.java PoolTcpConnector.java Stefan Freyr Stefansson Software Developer deCODE Genetics, Inc. Phone: (+354) 570 2854 GSM: (+354) 861 1718 Fax: (+354) 491 3782 Stefan Stefansson.vcf EmbededTomcat.java PoolTcpConnector.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
