RE: question on using multiple certificates in tomcat
Before TLS extension server name indication is implemented in server and browser (next year?), certificate is determined by which keystore is used. Keystore is determined by which connection is used, which means the certificate selection is driven by the IP address port number. A keystore is expected to only have one certificate in it. This is the one that is sent. HTH Martin -Original Message- From: Yanamula, Bharath [mailto:[EMAIL PROTECTED] Sent: 21 April 2004 19:46 To: '[EMAIL PROTECTED]' Subject: question on using multiple certificates in tomcat We have a Tomcat which is running with one servlet on https. This application uses one certificate, for authentication purposes. Now we are planning to develop another servlet to be placed on the same engine. We envisage this also to use a certificate. But the one it would use is a different one. I am new to this security and am trying to see what certificate would be sent when. That is, say I sending a https request from the first client application, would it send all the ertificates? Or would it just resolve it based on the name to which it is being sent to? Thanks in advance. CONFIDENTIALITY NOTICE: The information in this e-mail is privileged and confidential. Any use, copying or dissemination of any portion of this e-mail by or to anyone other than the intended recipient(s) is unauthorized. If you have received this e-mail in error, please reply to sender and delete it from your system immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: tomcat 4 vs 5 form based container auth filters
FYI this is catered for in tomcat 5 with the filter-mapping/dispatcher element (see servlet 2.4 spec). Thanks to Bill Barker for the info. Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 13 April 2004 16:35 To: 'Tomcat Users List' Subject: RE: tomcat 4 vs 5 form based container auth filters Anyone? -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 16:42 To: 'Tomcat Users List' Subject: RE: tomcat 4 vs 5 form based container auth filters Thanks Adam It seems to me that the separation idea is not clear cut. There is certainly a down side. I wonder whether this will stick. Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 13:48 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters I can see Yoav is blitzing the mailing list right now. Perhaps you'll get a more authoritative answer from him or the other hardcore tomcat people. One of the problems of excluding filters from the authentication request is to do with character-encoding in the request - I remember someone whose realm included users with user-names containing accented characters that had to be converted to the correct character-encoding for the realm database. He had used a filter to do it but obviously had to find another way. Adam On 04/12/2004 02:34 PM Martin Alley wrote: Except with form based auth, you want the look at feel to be part of the application? What reasons did you hear? :-) Whilst not knowing the full reasons, it would be nice if there was some config switch to control this, other wise it increases application maintainence overhead if you want to change the look and feel. I'll see if I can find anything in the tc5 release notes on this. Thanks again Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 13:13 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters AFAIK it has something to do with providing a clean seperation between the authentication (tomcat) and the application (your filter). I think there were probably several reasons though for it, which outweighed the reasons against, and I have heard a few of them. Adam On 04/12/2004 01:50 PM Martin Alley wrote: Hi Adam, Why do you think this behaviour changed from tomcat4 ? I haven't gone into the full architecture of sitemesh, as yet, but I know it includes a filter. Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 11:26 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters Yes your observations are correct. It's my understanding that filters are not invoked until after authentication. i.e. after the form-based login. I have no experience of site-mesh, but it seems a bit weird anyway to put decorations on a page via a filter - surely you should be encapsulating that sort of stuff in a JSP or taglib? Adam On 04/12/2004 11:02 AM Martin Alley wrote: Can anyone comment on this? Thanks Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 09 April 2004 09:53 To: Tomcat Users List Subject: tomcat 4 vs 5 form based container auth filters Hi, Initial observation indicates that filters get executed when a form for form based container auth is served - under tomcat 4, but not under tomcat 5. I'm using sitemesh. The decorations go on the form based login page under tomcat 4, but not under tomcat 5. I need to do more research, but can any one add to this? Thanks Martin - 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] -- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian - 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] - 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: SESSION PROBLEM in UNIX
Do you know how the session is being tracked in the browser? Cookie,
url? Are you saying you use the same browser in each case? Can you log
the http traffic?
Martin
-Original Message-
From: MUKUND Premchander [mailto:[EMAIL PROTECTED]
Sent: 15 April 2004 04:26
To: Tomcat Users List
Subject: RE: SESSION PROBLEM in UNIX
hi,
Thank you for your reply and suggestion .
I have only one user and one browser window and I get this problem .
I also like to mention that in the starting of the JSP if I added a line
of code like session = request.getSession(false),
then I don't get this problem at all .But I am not able to understand
why access to the session variable gives exception
suddenly after some refresh if I don't do this.Also I checked the codes
, no session invalidation is done nor a new session is created anywhere.
Thanks and Regards
Mukund
-Original Message-
From: Yansheng Lin [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 2:24 AM
To: 'Tomcat Users List'
Subject: RE: SESSION PROBLEM in UNIX
Hi, How about implementing HttpSessionListener so that you know when
your session is getting created and destroyed? Also do you have
multiple users running the same jsp? If you do, you may want to
synchronize that block of code.
Hope this helps:).
-Yan
-Original Message-
From: MUKUND Premchander [mailto:[EMAIL PROTECTED]
Sent: April 14, 2004 07:41
To: Tomcat Users List
Subject: SESSION PROBLEM in UNIX
Hi,
I have a jsp page which is refreshed atuomatically every 10 seconds.I
get and put values in the session by using the implicit session variable
. Everything works fine for say 2-3 mins after that the implicit session
becomes null and throws a null pointer exception.
I get a null pointer exception and session is printed as null but even
the if block (session == null) is not executed .
I printed the value of request.getSession(false);.This gives me session
object ,where as the implicit session does not have this after many
refresh interval
During the first few refreshes both have the same value.
Also note that this runs fine in Windows ,I get this problem only in
UNIX . I use tomcat 3.2 in unix and view using IE in windows
I tried in tomcat 4 also I still get the same exception
FIND below the code in JSP
try{
if (session == null){
System.out.println(session is null:::);
}
System.out.println(session3:::+session.toString());
if (session.isNew()) {
System.out.println(HI);
session.setAttribute(BPRealtimeConstants.C_JPM_SESSION_FAIL_ID,failed)
;
response.setHeader(Refresh,1; URL=/MCOne/BP/index.html);
return;
}
} catch (Exception e) {
System.out.println(I am in exception );
System.out.println(I am after hello
+request.getSession(false));
e.printStackTrace();
}
I am unble to find any resource on the net which might help me identify
the problem ,I am posting this for the second time . Can there be any
difference in session handling when tomcat is run in unix and Windows.
Any inputs will really help me solve this production problem
Thanks and Regards
Mukund
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: tomcat 4 vs 5 form based container auth filters
Anyone? -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 16:42 To: 'Tomcat Users List' Subject: RE: tomcat 4 vs 5 form based container auth filters Thanks Adam It seems to me that the separation idea is not clear cut. There is certainly a down side. I wonder whether this will stick. Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 13:48 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters I can see Yoav is blitzing the mailing list right now. Perhaps you'll get a more authoritative answer from him or the other hardcore tomcat people. One of the problems of excluding filters from the authentication request is to do with character-encoding in the request - I remember someone whose realm included users with user-names containing accented characters that had to be converted to the correct character-encoding for the realm database. He had used a filter to do it but obviously had to find another way. Adam On 04/12/2004 02:34 PM Martin Alley wrote: Except with form based auth, you want the look at feel to be part of the application? What reasons did you hear? :-) Whilst not knowing the full reasons, it would be nice if there was some config switch to control this, other wise it increases application maintainence overhead if you want to change the look and feel. I'll see if I can find anything in the tc5 release notes on this. Thanks again Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 13:13 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters AFAIK it has something to do with providing a clean seperation between the authentication (tomcat) and the application (your filter). I think there were probably several reasons though for it, which outweighed the reasons against, and I have heard a few of them. Adam On 04/12/2004 01:50 PM Martin Alley wrote: Hi Adam, Why do you think this behaviour changed from tomcat4 ? I haven't gone into the full architecture of sitemesh, as yet, but I know it includes a filter. Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 11:26 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters Yes your observations are correct. It's my understanding that filters are not invoked until after authentication. i.e. after the form-based login. I have no experience of site-mesh, but it seems a bit weird anyway to put decorations on a page via a filter - surely you should be encapsulating that sort of stuff in a JSP or taglib? Adam On 04/12/2004 11:02 AM Martin Alley wrote: Can anyone comment on this? Thanks Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 09 April 2004 09:53 To: Tomcat Users List Subject: tomcat 4 vs 5 form based container auth filters Hi, Initial observation indicates that filters get executed when a form for form based container auth is served - under tomcat 4, but not under tomcat 5. I'm using sitemesh. The decorations go on the form based login page under tomcat 4, but not under tomcat 5. I need to do more research, but can any one add to this? Thanks Martin - 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] -- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: tomcat 4 vs 5 form based container auth filters
Can anyone comment on this? Thanks Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 09 April 2004 09:53 To: Tomcat Users List Subject: tomcat 4 vs 5 form based container auth filters Hi, Initial observation indicates that filters get executed when a form for form based container auth is served - under tomcat 4, but not under tomcat 5. I'm using sitemesh. The decorations go on the form based login page under tomcat 4, but not under tomcat 5. I need to do more research, but can any one add to this? Thanks Martin - 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: tomcat 4 vs 5 form based container auth filters
Hi Adam, Why do you think this behaviour changed from tomcat4 ? I haven't gone into the full architecture of sitemesh, as yet, but I know it includes a filter. Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 11:26 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters Yes your observations are correct. It's my understanding that filters are not invoked until after authentication. i.e. after the form-based login. I have no experience of site-mesh, but it seems a bit weird anyway to put decorations on a page via a filter - surely you should be encapsulating that sort of stuff in a JSP or taglib? Adam On 04/12/2004 11:02 AM Martin Alley wrote: Can anyone comment on this? Thanks Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 09 April 2004 09:53 To: Tomcat Users List Subject: tomcat 4 vs 5 form based container auth filters Hi, Initial observation indicates that filters get executed when a form for form based container auth is served - under tomcat 4, but not under tomcat 5. I'm using sitemesh. The decorations go on the form based login page under tomcat 4, but not under tomcat 5. I need to do more research, but can any one add to this? Thanks Martin - 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] -- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian - 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: tomcat 4 vs 5 form based container auth filters
Except with form based auth, you want the look at feel to be part of the application? What reasons did you hear? :-) Whilst not knowing the full reasons, it would be nice if there was some config switch to control this, other wise it increases application maintainence overhead if you want to change the look and feel. I'll see if I can find anything in the tc5 release notes on this. Thanks again Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 13:13 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters AFAIK it has something to do with providing a clean seperation between the authentication (tomcat) and the application (your filter). I think there were probably several reasons though for it, which outweighed the reasons against, and I have heard a few of them. Adam On 04/12/2004 01:50 PM Martin Alley wrote: Hi Adam, Why do you think this behaviour changed from tomcat4 ? I haven't gone into the full architecture of sitemesh, as yet, but I know it includes a filter. Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 11:26 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters Yes your observations are correct. It's my understanding that filters are not invoked until after authentication. i.e. after the form-based login. I have no experience of site-mesh, but it seems a bit weird anyway to put decorations on a page via a filter - surely you should be encapsulating that sort of stuff in a JSP or taglib? Adam On 04/12/2004 11:02 AM Martin Alley wrote: Can anyone comment on this? Thanks Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 09 April 2004 09:53 To: Tomcat Users List Subject: tomcat 4 vs 5 form based container auth filters Hi, Initial observation indicates that filters get executed when a form for form based container auth is served - under tomcat 4, but not under tomcat 5. I'm using sitemesh. The decorations go on the form based login page under tomcat 4, but not under tomcat 5. I need to do more research, but can any one add to this? Thanks Martin - 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] -- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian - 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: tomcat 4 vs 5 form based container auth filters
Thanks Adam It seems to me that the separation idea is not clear cut. There is certainly a down side. I wonder whether this will stick. Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 13:48 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters I can see Yoav is blitzing the mailing list right now. Perhaps you'll get a more authoritative answer from him or the other hardcore tomcat people. One of the problems of excluding filters from the authentication request is to do with character-encoding in the request - I remember someone whose realm included users with user-names containing accented characters that had to be converted to the correct character-encoding for the realm database. He had used a filter to do it but obviously had to find another way. Adam On 04/12/2004 02:34 PM Martin Alley wrote: Except with form based auth, you want the look at feel to be part of the application? What reasons did you hear? :-) Whilst not knowing the full reasons, it would be nice if there was some config switch to control this, other wise it increases application maintainence overhead if you want to change the look and feel. I'll see if I can find anything in the tc5 release notes on this. Thanks again Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 13:13 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters AFAIK it has something to do with providing a clean seperation between the authentication (tomcat) and the application (your filter). I think there were probably several reasons though for it, which outweighed the reasons against, and I have heard a few of them. Adam On 04/12/2004 01:50 PM Martin Alley wrote: Hi Adam, Why do you think this behaviour changed from tomcat4 ? I haven't gone into the full architecture of sitemesh, as yet, but I know it includes a filter. Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 12 April 2004 11:26 To: Tomcat Users List Subject: Re: tomcat 4 vs 5 form based container auth filters Yes your observations are correct. It's my understanding that filters are not invoked until after authentication. i.e. after the form-based login. I have no experience of site-mesh, but it seems a bit weird anyway to put decorations on a page via a filter - surely you should be encapsulating that sort of stuff in a JSP or taglib? Adam On 04/12/2004 11:02 AM Martin Alley wrote: Can anyone comment on this? Thanks Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 09 April 2004 09:53 To: Tomcat Users List Subject: tomcat 4 vs 5 form based container auth filters Hi, Initial observation indicates that filters get executed when a form for form based container auth is served - under tomcat 4, but not under tomcat 5. I'm using sitemesh. The decorations go on the form based login page under tomcat 4, but not under tomcat 5. I need to do more research, but can any one add to this? Thanks Martin - 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] -- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian - 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: Session behaviour across http/https boundary
Hi Bill, Thanks for clarifying. BTW Do you know if this policy in the browser, or if tomcat uses the refer header to implement it on the server? Thanks Martin -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Bill Barker Sent: 09 April 2004 06:22 To: [EMAIL PROTECTED] Subject: Re: Session behaviour across http/https boundary Martin Alley [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, I have a small web app that appears to illustrate the following behaviour. Session started in http is carried over to https, but session started in https is *not* carried over to http! Why? This is for security reasons (so that it isn't possible to steal sensitive information that was entered in via SSL). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat 4 vs 5 form based container auth filters
Hi, Initial observation indicates that filters get executed when a form for form based container auth is served - under tomcat 4, but not under tomcat 5. I'm using sitemesh. The decorations go on the form based login page under tomcat 4, but not under tomcat 5. I need to do more research, but can any one add to this? Thanks Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Session behaviour across http/https boundary
Hi, I have a small web app that appears to illustrate the following behaviour. Session started in http is carried over to https, but session started in https is *not* carried over to http! Why? Web app has 3 pages Index.jsp Page2.jsp Logout.jsp (does session invalidate forward to index.jsp) 1) go to index.jsp as http (session1) 2) follow https link to page2.jsp (session1) 3) follow https link to logout.jsp 4) now at https index.jsp with session2 (session2 created in https world) 5) follow https link to page2.jsp again (session2) 6) follow *http* link to index.jsp (session 3!!!) I don't understand why session 3 is created. I read that old browsers don't maintain sessions between http and https; I'm using Ie6 Can anyone explain this? Thanks Martin PS Code is below. **Index.jsp %@ page import=javax.servlet.*, javax.servlet.http.*, org.apache.commons.logging.*% html body % HttpServletRequest req = ( HttpServletRequest ) request; HttpSession mysession = req.getSession(false ); Log __log = LogFactory.getLog( this.getClass() ); __log.info(index.jsp); __log.info(SessionID=+(mysession==null?null:mysession.getId())); % p SessionID=%=(mysession==null?null:mysession.getId())%br/ /p p a href=%=response.encodeURL(https://localhost:8443/sessiontest/page2.js p)%page2/a a href=%=response.encodeURL(https://localhost:8443/sessiontest/logout.j sp)%logout/abr/ /p /body /html page2.jsp %@ page import= javax.servlet.*, javax.servlet.http.*, org.apache.commons.logging.*% html body % HttpServletRequest req = ( HttpServletRequest ) request; HttpSession mysession = req.getSession(false ); Log __log = LogFactory.getLog( this.getClass() ); __log.info(page2); __log.info(SessionID=+(mysession==null?null:mysession.getId())); % p SessionID=%=(mysession==null?null:mysession.getId())%br/ /p p a href=%=response.encodeURL(http://localhost:8080/sessiontest/index.jsp )%index page/abr/ a href=%=response.encodeURL(https://localhost:8443/sessiontest/logout.j sp)%logout/abr/ /p /body /html *logout.jsp %@ page import= javax.servlet.*, javax.servlet.http.*, org.apache.commons.logging.*% % HttpServletRequest req = ( HttpServletRequest ) request; HttpSession mysession = req.getSession(false ); Log __log = LogFactory.getLog( this.getClass() ); __log.info(logout.jsp); __log.info(pre invalidate SessionID=+(mysession==null?null:mysession.getId())); if (session!=null) session.invalidate(); __log.info(post invalidateSessionID=+(mysession==null?null:mysession.getId())); RequestDispatcher rd =req.getRequestDispatcher(/index.jsp); rd.forward(req, (HttpServletResponse)response); % - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Session behaviour across http/https boundary
Hi, I have a small web app that appears to illustrate the following behaviour. Session started in http is carried over to https, but session started in https is *not* carried over to http! Why? Web app has 3 pages Index.jsp Page2.jsp Logout.jsp (does session invalidate forward to index.jsp) 1) go to index.jsp as http (session1) 2) follow https link to page2.jsp (session1) 3) follow https link to logout.jsp 4) now at https index.jsp with session2 (session2 created in https world) 5) follow https link to page2.jsp again (session2) 6) follow *http* link to index.jsp (session 3!!!) I don't understand why session 3 is created. I read that old browsers don't maintain sessions between http and https; I'm using Ie6 Can anyone explain this? Thanks Martin PS Code is below. **Index.jsp %@ page import=javax.servlet.*, javax.servlet.http.*, org.apache.commons.logging.*% html body % HttpServletRequest req = ( HttpServletRequest ) request; HttpSession mysession = req.getSession(false ); Log __log = LogFactory.getLog( this.getClass() ); __log.info(index.jsp); __log.info(SessionID=+(mysession==null?null:mysession.getId())); % p SessionID=%=(mysession==null?null:mysession.getId())%br/ /p p a href=%=response.encodeURL(https://localhost:8443/sessiontest/page2.js p)%page2/a a href=%=response.encodeURL(https://localhost:8443/sessiontest/logout.j sp)%logout/abr/ /p /body /html page2.jsp %@ page import= javax.servlet.*, javax.servlet.http.*, org.apache.commons.logging.*% html body % HttpServletRequest req = ( HttpServletRequest ) request; HttpSession mysession = req.getSession(false ); Log __log = LogFactory.getLog( this.getClass() ); __log.info(page2); __log.info(SessionID=+(mysession==null?null:mysession.getId())); % p SessionID=%=(mysession==null?null:mysession.getId())%br/ /p p a href=%=response.encodeURL(http://localhost:8080/sessiontest/index.jsp )%index page/abr/ a href=%=response.encodeURL(https://localhost:8443/sessiontest/logout.j sp)%logout/abr/ /p /body /html *logout.jsp %@ page import= javax.servlet.*, javax.servlet.http.*, org.apache.commons.logging.*% % HttpServletRequest req = ( HttpServletRequest ) request; HttpSession mysession = req.getSession(false ); Log __log = LogFactory.getLog( this.getClass() ); __log.info(logout.jsp); __log.info(pre invalidate SessionID=+(mysession==null?null:mysession.getId())); if (session!=null) session.invalidate(); __log.info(post invalidateSessionID=+(mysession==null?null:mysession.getId())); RequestDispatcher rd =req.getRequestDispatcher(/index.jsp); rd.forward(req, (HttpServletResponse)response); % - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How does Tomcat manage Form-based authentication?
It sends you the html form you specify in the form-login-config section of web.xml See chapter 12 (Security) Appendix A (Deployment Descriptor) of Servlet Spec 2.3 for details. http://java.sun.com/products/servlet/download.html#specs Martin -Original Message- From: Malcolm Warren [mailto:[EMAIL PROTECTED] Sent: 01 April 2004 15:39 To: Tomcat Users List Subject: How does Tomcat manage Form-based authentication? With BASIC authorization, which I used to use, the browser was sent an Authorization header. This doesn't happen with FORM-based authorization. I believe Tomcat deals with it all, but how? Anybody know? - 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]
Multiple certificates for multiple virtual hosts (1:1)
Hi, I want to have different certificates for different virtual hosts on my tomcat setup (embedded in JBoss). I only have 1 IP address. I want to use the default ports (80 443) for each virtual server. A certificate doesn't say anything about the IP address - only the common name (ie the FQDN). It is perfectly possible to change the IP address of the machine on which the cert is installed, and not have to update the certificate. Just let DNS update round the world. The key thing is to keep the private key that is paired with the public key embedded in the cert (that's been signed by the CA) secured on the same machine. Tomcat: The Definitive Guide, has this to say about multiple server certificates: Suppose you are an ISP with clients, several of whom want to have their own certificate. Typically this would involve using Virtual Hosts (as covered in Chapter 7). Simply add an SSL Factory element to the appropriate client's Connector, giving the keystore file for that specific client. I don't see how virtual hosts are associated directly with certificates. From my reading, certificates are associated with keystore, which are associated with connectors, which are globally shared by one engine. In other words it seems you can have different certs for different *ports*, and you can use any of the virtual host names with any of the ports declared, but you can't have the appropriate cert selected based on the host name. This is a shame, because *that* is what has been certified! So, suppose I have 2 pairs of HTTP connectors each with an SSL factory: Http 80 with SSL 443 (cert common name www.company1.com) Http 8080 with SSL 8443 (cert common name www.company2.com) And I have virtual hosts www.company1.com and www.company2.com It seems to me the certificate I will get presented would depend on the port number entered, and not the virtual host name. Thus there exists potential for a name mismatch between the requested url, and the common name in the certificate - which is a bad thing. https://www.company1.com works and gets the right cert https://www.company1.com:8443 works, but gets a warning because of the mismatched cert Tomcat 5 SSL howto states: In order to implement SSL, a web server must have an associated Certificate for each external interface (IP address) that accepts secure connections. Ignoring my assertions about the irrelevance of IP address above, I don't understand how a specific IP address is associated with a specific certificate in server.xml Can someone put me right on this? Or provide a example server.xml of what I want to achieve? Thanks Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Of .war and .jar files - and .jsp class files
Stick the class files in WEB-INF/classes in the appropriate package hierarchy. Eg. Com.mycompany.myclass in WEB-INF/classes/com/mycompany/myclass.class -Original Message- From: Malcolm Warren [mailto:[EMAIL PROTECTED] Sent: 31 March 2004 11:03 To: [EMAIL PROTECTED] Subject: Of .war and .jar files - and .jsp class files I am changing from Jrun to Tomcat and I have just one problem remaining. Jrun gave an additional security possibility that I am unable to extend to Tomcat. In Jrun you do not need to place your .jsp files, nor the automatically generated .java files on your production server. I could simply .jar up the automatically generated .class files and place the .jar file in the /WEB-INF/jsp folder on the production server. That way I had 3 big advantages: 1) Nobody could look into my .jsp files. 2) Nobody could look into my .java files for my .jsps 3) Compilation on the production server of the .jsps was already done. - Everything was ready in the single .jar file. Now perhaps I am missing something, so please put me right. And I'm just starting now to use ant and I've never bothered with .war files because I don't distribute my programmes, they're just used on our production server. If I create a .war file for the production server then the .war file contains no compiled .jsps, just the original .jsp files - is that right? There seem to me to be obvious advantages to what I was able to do in Jrun - can I do something similar in Tomcat? In general I get many more security features with Tomcat 4.1, than I did with Jrun 3.1, but this particular possibility seems to me to be a good one. I have tried creating .jar files of the Tomcat's /work directory but without any success. Can anybody enlighten me? Thanks for any help. Regards, Malcolm Warren - 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: Multiple certificates for multiple virtual hosts (1:1)
Okay, I see that the address attribute of the connector element can be used to retrict IP/port combinations. As I've only got 1 IP this doesn't really affect me. Either I've misunderstood something fundamental, or the configuration capabilities are not optimal. Any one? Thanks Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 31 March 2004 12:10 To: Tomcat Users List Subject: Multiple certificates for multiple virtual hosts (1:1) Hi, I want to have different certificates for different virtual hosts on my tomcat setup (embedded in JBoss). I only have 1 IP address. I want to use the default ports (80 443) for each virtual server. A certificate doesn't say anything about the IP address - only the common name (ie the FQDN). It is perfectly possible to change the IP address of the machine on which the cert is installed, and not have to update the certificate. Just let DNS update round the world. The key thing is to keep the private key that is paired with the public key embedded in the cert (that's been signed by the CA) secured on the same machine. Tomcat: The Definitive Guide, has this to say about multiple server certificates: Suppose you are an ISP with clients, several of whom want to have their own certificate. Typically this would involve using Virtual Hosts (as covered in Chapter 7). Simply add an SSL Factory element to the appropriate client's Connector, giving the keystore file for that specific client. I don't see how virtual hosts are associated directly with certificates. From my reading, certificates are associated with keystore, which are associated with connectors, which are globally shared by one engine. In other words it seems you can have different certs for different *ports*, and you can use any of the virtual host names with any of the ports declared, but you can't have the appropriate cert selected based on the host name. This is a shame, because *that* is what has been certified! So, suppose I have 2 pairs of HTTP connectors each with an SSL factory: Http 80 with SSL 443 (cert common name www.company1.com) Http 8080 with SSL 8443 (cert common name www.company2.com) And I have virtual hosts www.company1.com and www.company2.com It seems to me the certificate I will get presented would depend on the port number entered, and not the virtual host name. Thus there exists potential for a name mismatch between the requested url, and the common name in the certificate - which is a bad thing. https://www.company1.com works and gets the right cert https://www.company1.com:8443 works, but gets a warning because of the mismatched cert Tomcat 5 SSL howto states: In order to implement SSL, a web server must have an associated Certificate for each external interface (IP address) that accepts secure connections. Ignoring my assertions about the irrelevance of IP address above, I don't understand how a specific IP address is associated with a specific certificate in server.xml Can someone put me right on this? Or provide a example server.xml of what I want to achieve? Thanks Martin - 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: Multiple certificates for multiple virtual hosts (1:1)
Hi Doug, I guess my point is that given there may be multiple certificates installed on a web server, and given that certificates authenticate Distinguished Name there should be an effective way to make sure the correct certificate is sent to the user. The certificate isn't just for viewing on the client when there is a name mismatch, or out of date of whatever - it can be used by SSL 3 supported RSA key exchange. Why should the user get the wrong certificate when the correct one is available??? I understand about SSL fitting between TCP/IP and HTTP in the protocol stack. I would expect the host name to transition as part of the SSL session initiation - given that the certificate authenticates the *name* and not the IP address!! It looks like this has already been considered by the gurus (not surprisingly :-) http://ietf.org/internet-drafts/draft-ietf-tls-emailaddr-00.txt I shall do a bit more research... Cheers Martin -Original Message- From: Parsons Technical Services [mailto:[EMAIL PROTECTED] Sent: 31 March 2004 14:55 To: Tomcat Users List Subject: Re: Multiple certificates for multiple virtual hosts (1:1) Martin, You missed something fundamental. See the following document for a brief description of the problem. http://jakarta.apache.org/tomcat/tomcat-4.1-doc/ssl-howto.html For a more detailed description see: http://httpd.apache.org/docs-2.0/ssl/ssl_intro.html Short answer you can't. I have an idea about a work around using non-standard ports: Short version- No connectors on 443. Redirect or link from http page to https nonstandard port. Has anyone tried this or have it working Doug www.parsonstechnical.com - Original Message - From: Martin Alley [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 8:39 AM Subject: RE: Multiple certificates for multiple virtual hosts (1:1) Okay, I see that the address attribute of the connector element can be used to retrict IP/port combinations. As I've only got 1 IP this doesn't really affect me. Either I've misunderstood something fundamental, or the configuration capabilities are not optimal. Any one? Thanks Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 31 March 2004 12:10 To: Tomcat Users List Subject: Multiple certificates for multiple virtual hosts (1:1) Hi, I want to have different certificates for different virtual hosts on my tomcat setup (embedded in JBoss). I only have 1 IP address. I want to use the default ports (80 443) for each virtual server. A certificate doesn't say anything about the IP address - only the common name (ie the FQDN). It is perfectly possible to change the IP address of the machine on which the cert is installed, and not have to update the certificate. Just let DNS update round the world. The key thing is to keep the private key that is paired with the public key embedded in the cert (that's been signed by the CA) secured on the same machine. Tomcat: The Definitive Guide, has this to say about multiple server certificates: Suppose you are an ISP with clients, several of whom want to have their own certificate. Typically this would involve using Virtual Hosts (as covered in Chapter 7). Simply add an SSL Factory element to the appropriate client's Connector, giving the keystore file for that specific client. I don't see how virtual hosts are associated directly with certificates. From my reading, certificates are associated with keystore, which are associated with connectors, which are globally shared by one engine. In other words it seems you can have different certs for different *ports*, and you can use any of the virtual host names with any of the ports declared, but you can't have the appropriate cert selected based on the host name. This is a shame, because *that* is what has been certified! So, suppose I have 2 pairs of HTTP connectors each with an SSL factory: Http 80 with SSL 443 (cert common name www.company1.com) Http 8080 with SSL 8443 (cert common name www.company2.com) And I have virtual hosts www.company1.com and www.company2.com It seems to me the certificate I will get presented would depend on the port number entered, and not the virtual host name. Thus there exists potential for a name mismatch between the requested url, and the common name in the certificate - which is a bad thing. https://www.company1.com works and gets the right cert https://www.company1.com:8443 works, but gets a warning because of the mismatched cert Tomcat 5 SSL howto states: In order to implement SSL, a web server must have an associated Certificate for each external interface (IP address) that accepts secure connections. Ignoring my assertions about the irrelevance of IP address above, I don't understand how a specific IP address is associated with a specific certificate in server.xml Can someone put me right on this? Or provide a example
RE: post data through form based authentication example?
No formal bug report yet. The current state of play is at http://www.jboss.org/index.html?module=bbop=viewtopict=47595 If you would like to add your weight to this observation... Thanks Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 29 March 2004 09:17 To: Tomcat Users List Subject: Re: post data through form based authentication example? Hmm. You're right. I just tested it on my JBoss (running 3.2.4RC1 with tomcat 5.0.19) and I got the same effect. Rats! This is not good. Trying to get info out of JBoss is like trying to get blood out of a stones. I assume there's a bug report? I haven't looked at JBoss's bugzilla yet. On 03/29/2004 01:10 AM Martin Alley wrote: After further testing, I believe this is a bug specific to the JBoss environment (both 3.2.3 and 3.2.4RC1) Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 28 March 2004 15:24 To: 'Tomcat Users List' Subject: RE: post data through form based authentication example? The updated web.xml below now correctly lists the required security-role tags, but the only effect was to bring the form.html resource into the secured area (ie login is requested before accessing this page now), so I have also modified web.xml to put form.html *outside* the secured area - thus still requiring post data to transition the form based logon. ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app session-config session-timeout2/session-timeout /session-config security-constraint web-resource-collection web-resource-nameSignon/web-resource-name descriptionDeclarative security tests/description !--url-pattern/form.html/url-pattern-- url-pattern/process.jsp/url-pattern http-methodHEAD/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint role-namecustomer/role-name role-namemerchant/role-name role-nameadmin/role-name /auth-constraint user-data-constraint descriptionno description/description transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.html/form-login-page form-error-page/login.html/form-error-page /form-login-config /login-config security-rolerole-namecustomer/role-name/security-role security-rolerole-namemerchant/role-name/security-role security-rolerole-nameadmin/role-name/security-role /web-app I can't see the point of protecting the POST method if the data fails to transition. Has anyone got a working example of this? Thanks Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 09:47 To: 'Tomcat Users List' Subject: RE: post data through form based authentication example? I forgot to mention it's behaviour!! Basically when the is no security constraint, it works. When there is a security constraint, the post data gets killed. Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 09:43 To: 'Tomcat Users List' Subject: RE: post data through form based authentication example? Hi Adam, I've put together a simple test for posting to a secured resource which seems to throw up a problem. Included files are the web app. Based on JBoss3.2.3 embedded tomcat4.1. Martin Index.html html body a href=form.htmlform/a /body /html form.html html body form action=process.jsp method=post input type=text name=text1/ input type=submit value=OK/ /form /body /html login.html html body h4Please login:/h4 form method=POST action=j_security_check input type=text name=j_username input type=password name=j_password input type=submit value=OK /form /body /html process.jsp html body text1=%=request.getParameter(text1)% /body /html WEB-INF\web.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app session-config session-timeout2/session-timeout /session-config security-constraint web-resource-collection web-resource-nameSignon/web-resource-name descriptionDeclarative security tests/description url-pattern/form.html/url-pattern
RE: post data through form based authentication example?
The updated web.xml below now correctly lists the required security-role tags, but the only effect was to bring the form.html resource into the secured area (ie login is requested before accessing this page now), so I have also modified web.xml to put form.html *outside* the secured area - thus still requiring post data to transition the form based logon. ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app session-config session-timeout2/session-timeout /session-config security-constraint web-resource-collection web-resource-nameSignon/web-resource-name descriptionDeclarative security tests/description !--url-pattern/form.html/url-pattern-- url-pattern/process.jsp/url-pattern http-methodHEAD/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint role-namecustomer/role-name role-namemerchant/role-name role-nameadmin/role-name /auth-constraint user-data-constraint descriptionno description/description transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.html/form-login-page form-error-page/login.html/form-error-page /form-login-config /login-config security-rolerole-namecustomer/role-name/security-role security-rolerole-namemerchant/role-name/security-role security-rolerole-nameadmin/role-name/security-role /web-app I can't see the point of protecting the POST method if the data fails to transition. Has anyone got a working example of this? Thanks Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 09:47 To: 'Tomcat Users List' Subject: RE: post data through form based authentication example? I forgot to mention it's behaviour!! Basically when the is no security constraint, it works. When there is a security constraint, the post data gets killed. Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 09:43 To: 'Tomcat Users List' Subject: RE: post data through form based authentication example? Hi Adam, I've put together a simple test for posting to a secured resource which seems to throw up a problem. Included files are the web app. Based on JBoss3.2.3 embedded tomcat4.1. Martin Index.html html body a href=form.htmlform/a /body /html form.html html body form action=process.jsp method=post input type=text name=text1/ input type=submit value=OK/ /form /body /html login.html html body h4Please login:/h4 form method=POST action=j_security_check input type=text name=j_username input type=password name=j_password input type=submit value=OK /form /body /html process.jsp html body text1=%=request.getParameter(text1)% /body /html WEB-INF\web.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app session-config session-timeout2/session-timeout /session-config security-constraint web-resource-collection web-resource-nameSignon/web-resource-name descriptionDeclarative security tests/description url-pattern/form.html/url-pattern url-pattern/process.jsp/url-pattern http-methodHEAD/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint role-namecustomer/role-name role-namemerchant/role-name role-nameadmin/role-name /auth-constraint user-data-constraint descriptionno description/description transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.html/form-login-page form-error-page/login.html/form-error-page /form-login-config /login-config /web-app WEB-INF\jboss-web.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE jboss-web PUBLIC -//JBoss//DTD Web Application 2.3//EN http://www.jboss.org/j2ee/dtd/jboss-web_3_0.dtd; jboss-web security-domainjava:/jaas/authtest/security-domain !-- Resource Environment References -- !-- Resource references
RE: post data through form based authentication example?
After further testing, I believe this is a bug specific to the JBoss environment (both 3.2.3 and 3.2.4RC1) Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 28 March 2004 15:24 To: 'Tomcat Users List' Subject: RE: post data through form based authentication example? The updated web.xml below now correctly lists the required security-role tags, but the only effect was to bring the form.html resource into the secured area (ie login is requested before accessing this page now), so I have also modified web.xml to put form.html *outside* the secured area - thus still requiring post data to transition the form based logon. ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app session-config session-timeout2/session-timeout /session-config security-constraint web-resource-collection web-resource-nameSignon/web-resource-name descriptionDeclarative security tests/description !--url-pattern/form.html/url-pattern-- url-pattern/process.jsp/url-pattern http-methodHEAD/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint role-namecustomer/role-name role-namemerchant/role-name role-nameadmin/role-name /auth-constraint user-data-constraint descriptionno description/description transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.html/form-login-page form-error-page/login.html/form-error-page /form-login-config /login-config security-rolerole-namecustomer/role-name/security-role security-rolerole-namemerchant/role-name/security-role security-rolerole-nameadmin/role-name/security-role /web-app I can't see the point of protecting the POST method if the data fails to transition. Has anyone got a working example of this? Thanks Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 09:47 To: 'Tomcat Users List' Subject: RE: post data through form based authentication example? I forgot to mention it's behaviour!! Basically when the is no security constraint, it works. When there is a security constraint, the post data gets killed. Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 09:43 To: 'Tomcat Users List' Subject: RE: post data through form based authentication example? Hi Adam, I've put together a simple test for posting to a secured resource which seems to throw up a problem. Included files are the web app. Based on JBoss3.2.3 embedded tomcat4.1. Martin Index.html html body a href=form.htmlform/a /body /html form.html html body form action=process.jsp method=post input type=text name=text1/ input type=submit value=OK/ /form /body /html login.html html body h4Please login:/h4 form method=POST action=j_security_check input type=text name=j_username input type=password name=j_password input type=submit value=OK /form /body /html process.jsp html body text1=%=request.getParameter(text1)% /body /html WEB-INF\web.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app session-config session-timeout2/session-timeout /session-config security-constraint web-resource-collection web-resource-nameSignon/web-resource-name descriptionDeclarative security tests/description url-pattern/form.html/url-pattern url-pattern/process.jsp/url-pattern http-methodHEAD/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint role-namecustomer/role-name role-namemerchant/role-name role-nameadmin/role-name /auth-constraint user-data-constraint descriptionno description/description transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.html/form-login-page form-error-page/login.html/form-error-page /form-login-config /login-config /web-app WEB
RE: post data through form based authentication example?
Hi Adam, I've put together a simple test for posting to a secured resource which seems to throw up a problem. Included files are the web app. Based on JBoss3.2.3 embedded tomcat4.1. Martin Index.html html body a href=form.htmlform/a /body /html form.html html body form action=process.jsp method=post input type=text name=text1/ input type=submit value=OK/ /form /body /html login.html html body h4Please login:/h4 form method=POST action=j_security_check input type=text name=j_username input type=password name=j_password input type=submit value=OK /form /body /html process.jsp html body text1=%=request.getParameter(text1)% /body /html WEB-INF\web.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app session-config session-timeout2/session-timeout /session-config security-constraint web-resource-collection web-resource-nameSignon/web-resource-name descriptionDeclarative security tests/description url-pattern/form.html/url-pattern url-pattern/process.jsp/url-pattern http-methodHEAD/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint role-namecustomer/role-name role-namemerchant/role-name role-nameadmin/role-name /auth-constraint user-data-constraint descriptionno description/description transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.html/form-login-page form-error-page/login.html/form-error-page /form-login-config /login-config /web-app WEB-INF\jboss-web.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE jboss-web PUBLIC -//JBoss//DTD Web Application 2.3//EN http://www.jboss.org/j2ee/dtd/jboss-web_3_0.dtd; jboss-web security-domainjava:/jaas/authtest/security-domain !-- Resource Environment References -- !-- Resource references -- !-- EJB References -- /jboss-web -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 25 March 2004 15:10 To: Tomcat Users List Subject: Re: post data through form based authentication example? Martin, I would check your problem again. That is not the normal behaviour of the container-managed login. It will cache the original request during the login and send it on to the originally requested URL. Adam On 03/25/2004 02:45 PM Martin Alley wrote: Hi, Has any one got an example of a servlet secured with form based authentication, where the request to the servlet is posted, from outside the secured area? My actual situation is I already have a web application with form based auth working fine, but I have a problem when the user is at a web form, about to post the data when their session times out. Then they submit the form, get sent to the login page, and then the on to the original form processing servlet. However the post data is now lost. I am using tomcat4.1 as bundled with JBoss 3.2.3 and the coyote connector. Thanks in advance Martin PS I have also posted to JBoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - 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: post data through form based authentication example?
I forgot to mention it's behaviour!! Basically when the is no security constraint, it works. When there is a security constraint, the post data gets killed. Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 09:43 To: 'Tomcat Users List' Subject: RE: post data through form based authentication example? Hi Adam, I've put together a simple test for posting to a secured resource which seems to throw up a problem. Included files are the web app. Based on JBoss3.2.3 embedded tomcat4.1. Martin Index.html html body a href=form.htmlform/a /body /html form.html html body form action=process.jsp method=post input type=text name=text1/ input type=submit value=OK/ /form /body /html login.html html body h4Please login:/h4 form method=POST action=j_security_check input type=text name=j_username input type=password name=j_password input type=submit value=OK /form /body /html process.jsp html body text1=%=request.getParameter(text1)% /body /html WEB-INF\web.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app session-config session-timeout2/session-timeout /session-config security-constraint web-resource-collection web-resource-nameSignon/web-resource-name descriptionDeclarative security tests/description url-pattern/form.html/url-pattern url-pattern/process.jsp/url-pattern http-methodHEAD/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint role-namecustomer/role-name role-namemerchant/role-name role-nameadmin/role-name /auth-constraint user-data-constraint descriptionno description/description transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodFORM/auth-method form-login-config form-login-page/login.html/form-login-page form-error-page/login.html/form-error-page /form-login-config /login-config /web-app WEB-INF\jboss-web.xml ?xml version=1.0 encoding=UTF-8? !DOCTYPE jboss-web PUBLIC -//JBoss//DTD Web Application 2.3//EN http://www.jboss.org/j2ee/dtd/jboss-web_3_0.dtd; jboss-web security-domainjava:/jaas/authtest/security-domain !-- Resource Environment References -- !-- Resource references -- !-- EJB References -- /jboss-web -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 25 March 2004 15:10 To: Tomcat Users List Subject: Re: post data through form based authentication example? Martin, I would check your problem again. That is not the normal behaviour of the container-managed login. It will cache the original request during the login and send it on to the originally requested URL. Adam On 03/25/2004 02:45 PM Martin Alley wrote: Hi, Has any one got an example of a servlet secured with form based authentication, where the request to the servlet is posted, from outside the secured area? My actual situation is I already have a web application with form based auth working fine, but I have a problem when the user is at a web form, about to post the data when their session times out. Then they submit the form, get sent to the login page, and then the on to the original form processing servlet. However the post data is now lost. I am using tomcat4.1 as bundled with JBoss 3.2.3 and the coyote connector. Thanks in advance Martin PS I have also posted to JBoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Same data source config on two contexts, different result
The differences I can see are in the Context element and the url param value. The question is what difference is significant. I would try making the second config more similar to the first, and see when it starts working. Eg. Is it because the url lookup is failing? Is it because it is no allowed to load the class from that url. Assuming the error message is misleading. Do you have a security policy file? Just a thought Martin -Original Message- From: Stig Stavik [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 09:55 To: [EMAIL PROTECTED] Subject: Same data source config on two contexts, different result Hi! I'm having difficulties setting up datasources! At the moment I have two contexts that I'm testing this on. The first is this one. It works fine. Context docBase=/home/stig/public_jsp path=/stig Resource name=nutshellTestSource type=javax.sql.DataSource/ ResourceParams name=nutshellTestSource parameter namemaxWait/name value5000/value /parameter parameter namemaxActive/name value4/value /parameter parameter namepassword/name valuea/value /parameter parameter nameurl/name valuejdbc:mysql://localhost:3306/dev/value /parameter parameter namedriverClassName/name valuecom.mysql.jdbc.Driver/value /parameter parameter namemaxIdle/name value2/value /parameter parameter nameusername/name valuestig/value /parameter /ResourceParams /Context The other one is on another v-host on the same server. However this one doesen't work at all. In the admin-webapp I get an exception when I try to view the datasource saying: javax.servlet.ServletException: Exception retrieving attribute 'driverClassName' Context docBase=ROOT path=/ reloadable=true Resource name=nutshellTestSource type=javax.sql.DataSource/ ResourceParams name=nutshellTestSource parameter namemaxWait/name value5000/value /parameter parameter namemaxActive/name value4/value /parameter parameter namepassword/name valuehest/value /parameter parameter nameurl/name valuejdbc:mysql://nutshell.vestkant.no:3306/dev/value /parameter parameter namedriverClassName/name valuecom.mysql.jdbc.Driver/value /parameter parameter namemaxIdle/name value2/value /parameter parameter nameusername/name valueflux/value /parameter /ResourceParams /Context This has really been bugging me over the past weeks! -- StSt - 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: Same data source config on two contexts, different result
So you can change any parameter and it still fails? Have you tried playing with the attributes in the context element? -Original Message- From: Stig Stavik [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 10:15 To: Tomcat Users List Subject: Re: Same data source config on two contexts, different result Martin Alley wrote: The differences I can see are in the Context element and the url param value. The question is what difference is significant. The URL have been switched back and forth, but with the same result. This goes for all the other parameters also - but in the end it's always the javax.servlet.ServletException: Exception retrieving attribute 'driverClassName' which is thrown in the admin-webapp. Do you have a security policy file? Nope. -- StSt - 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: Same data source config on two contexts, different result
Reloadable Docbase Path In that order. Martin -Original Message- From: Stig Stavik [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 10:32 To: Tomcat Users List Subject: Re: Same data source config on two contexts, different result Martin Alley wrote: So you can change any parameter and it still fails? Have you tried playing with the attributes in the context element? No, I haven't. What sort of playful attributes do you recomend? :) -- StSt - 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: Same data source config on two contexts, different result
Furthermore, I'm thinking about the semantics of the driver class and doc base. Do you have the driver class in the right place so it can be found when docroot is ROOT? -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 10:37 To: 'Tomcat Users List' Subject: RE: Same data source config on two contexts, different result Reloadable Docbase Path In that order. Martin -Original Message- From: Stig Stavik [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 10:32 To: Tomcat Users List Subject: Re: Same data source config on two contexts, different result Martin Alley wrote: So you can change any parameter and it still fails? Have you tried playing with the attributes in the context element? No, I haven't. What sort of playful attributes do you recomend? :) -- StSt - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Same data source config on two contexts, different result
What version of tomcat are you using? -Original Message- From: Stig Stavik [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 11:23 To: Tomcat Users List Subject: Re: Same data source config on two contexts, different result Martin Alley wrote: Do you have the driver class in the right place so it can be found when docroot is ROOT? As long as the connector is to be found in tomcats classpath, it should be ok, shouldn't it? Ok. New approach - total chaos. I removed the v-host and created a new one using the admin-tool. No datasource added this time. When I now press the datasource, I get the same error regarding the driverClassName. However, the logging for the new host works, and here the following is stated: java.lang.IllegalStateException: Context path / is already in use 2004-03-27 11:50:19 StandardHost[www.mydomain.com]: Error deploying application at context path null java.lang.IllegalStateException: Context path / is already in use at org.apache.commons.digester.Digester.createSAXException(Digester.java:25 40) . . . In spite of this, the v-host is working, and so does the other default-/ on the server. - 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: Same data source config on two contexts, different result
I believe the driver either needs to be in WEB-INF/lib or $CATALINA_HOME/common/lib Martin -Original Message- From: Stig Stavik [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 11:23 To: Tomcat Users List Subject: Re: Same data source config on two contexts, different result Martin Alley wrote: Do you have the driver class in the right place so it can be found when docroot is ROOT? As long as the connector is to be found in tomcats classpath, it should be ok, shouldn't it? Ok. New approach - total chaos. I removed the v-host and created a new one using the admin-tool. No datasource added this time. When I now press the datasource, I get the same error regarding the driverClassName. However, the logging for the new host works, and here the following is stated: java.lang.IllegalStateException: Context path / is already in use 2004-03-27 11:50:19 StandardHost[www.mydomain.com]: Error deploying application at context path null java.lang.IllegalStateException: Context path / is already in use at org.apache.commons.digester.Digester.createSAXException(Digester.java:25 40) . . . In spite of this, the v-host is working, and so does the other default-/ on the server. - 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: Same data source config on two contexts, different result
Is that where your other context is finding it also? Where else is the driver? If you remove it from $CATALINA_HOME/common/lib does the other context fail in the same way as the /stig context? -Original Message- From: Stig Stavik [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 11:45 To: Tomcat Users List Subject: Re: Same data source config on two contexts, different result Martin Alley wrote: I believe the driver either needs to be in WEB-INF/lib or $CATALINA_HOME/common/lib The driver is in $CATALINA_HOME/common/lib -- StSt - 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: Same data source config on two contexts, different result
Can you validate your config against a DTD? I find the wording of the error message suspicious - it sounds like it can't read the config file properly, rather than it can't find the driver file that is configured. Martin -Original Message- From: Martin Alley [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 11:49 To: 'Tomcat Users List' Subject: RE: Same data source config on two contexts, different result Is that where your other context is finding it also? Where else is the driver? If you remove it from $CATALINA_HOME/common/lib does the other context fail in the same way as the /stig context? -Original Message- From: Stig Stavik [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 11:45 To: Tomcat Users List Subject: Re: Same data source config on two contexts, different result Martin Alley wrote: I believe the driver either needs to be in WEB-INF/lib or $CATALINA_HOME/common/lib The driver is in $CATALINA_HOME/common/lib -- StSt - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Same data source config on two contexts, different result
I'm confused! An attribute that never should have been there??? I agree with Doug, please post full configs and the relevant code. -Original Message- From: Stig Stavik [mailto:[EMAIL PROTECTED] Sent: 27 March 2004 12:03 To: Tomcat Users List Subject: Re: Same data source config on two contexts, different result Martin Alley wrote: Can you validate your config against a DTD? Well, when I made a new context on the v-host, tomcat makes a config for me. Context docBase=/home/stig/blablabla/ path= useNaming=false /Context I haven't touched it - and I recon tomcat should be able to read its own config files! It's also a bit strange that it complains about a attribute which never should have been there in the first place since there is no datasource configured for that context. -- StSt - 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]
post data through form based authentication example?
Hi, Has any one got an example of a servlet secured with form based authentication, where the request to the servlet is posted, from outside the secured area? My actual situation is I already have a web application with form based auth working fine, but I have a problem when the user is at a web form, about to post the data when their session times out. Then they submit the form, get sent to the login page, and then the on to the original form processing servlet. However the post data is now lost. I am using tomcat4.1 as bundled with JBoss 3.2.3 and the coyote connector. Thanks in advance Martin PS I have also posted to JBoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: post data through form based authentication example?
Hi Adam, That's encouraging. I'm actually using struts in this app too. I'll do some debugging and see where I get. Thanks for now Martin -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: 25 March 2004 15:10 To: Tomcat Users List Subject: Re: post data through form based authentication example? Martin, I would check your problem again. That is not the normal behaviour of the container-managed login. It will cache the original request during the login and send it on to the originally requested URL. Adam On 03/25/2004 02:45 PM Martin Alley wrote: Hi, Has any one got an example of a servlet secured with form based authentication, where the request to the servlet is posted, from outside the secured area? My actual situation is I already have a web application with form based auth working fine, but I have a problem when the user is at a web form, about to post the data when their session times out. Then they submit the form, get sent to the login page, and then the on to the original form processing servlet. However the post data is now lost. I am using tomcat4.1 as bundled with JBoss 3.2.3 and the coyote connector. Thanks in advance Martin PS I have also posted to JBoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - 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]
NullPointerException running JSP samples in Cobalt RaQ4 tomcat installation
Hi, I'm pulling my hair out over this... Set up is Cobalt RaQ4 Sun Cobalt Developer Kit for Java (jdk 1.3.1 tomcat 3.2.1) I have two tests that fail: All samples in webapps/examples An html file call test.jsp in webapps/examples/jsp/ (file contains just html) The jsp seems to compile find, but fails like this: java.lang.NullPointerException at jsp._0002fjsp_0002ftest_0002ejsptest_jsp_1._jspService(_0002fjsp_0002ftest_0 002ejsptest_jsp_1.java:66) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection (Ajp12ConnectionHandler.java:166) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:484) The only config mods we have made following standard installation of the package is in workers.properties - set java_home tomcat_home and ps Turning on full debug info, the test.jsp gets compiled like this: 2001-09-01 09:03:56 - Compiling with: -encoding UTF8 -classpath /usr/java/jakarta-tomcat/lib/ant.jar: /usr/java/jakarta-tomcat/lib/jasper.jar: /usr/java/jakarta-tomcat/lib/jaxp.jar: /usr/java/jakarta-tomcat/lib/parser.jar: /usr/java/jakarta-tomcat/lib/servlet.jar: /usr/java/jakarta-tomcat/lib/test: /usr/java/jakarta-tomcat/lib/webserver.jar: /usr/java/jdk/lib/tools.jar: : .: /usr/java/jakarta-tomcat/lib/servlet.jar: /usr/interclient/interclient.jar: /usr/java/jakarta-tomcat-3.2.1/webapps/examples/WEB-INF/classes: null: /usr/java/jakarta-tomcat-3.2.1/work/localhost_8080%2Fexamples Any help much appreciated Thanks Martin Imerge Limited Tel :- +44 (0)1954 783600 Unit 6 Bar Hill Business Park Fax :- +44 (0)1954 783601 Saxon Way Web :- http://www.imerge.co.uk Bar Hill Cambridge CB3 8SL United Kingdom
