The rules are: 1) If you aren't using Cookies, then you get a new session everytime you change from HTTPS to HTTP or from HTTP to HTTPS. 2) If you are using Cookies and first establish your session via HTTP, then that session is shared between HTTP and HTTPS requests. 3) If you are using Cookies and first establish your session via HTTPS, then you will get a new session when you change to HTTP. After that, rule 2) applies.
"Murray" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Gentlemen, > > Can one of you please elaborate a little on this for me? I have an insecure > index.jsp page which, by default, establishes a session upon loading. > > Now, as I understand the authentication process, once I jump to a page in > the secure area I will be driven to my logon form (using JDBC Realm and > form based auth) and will have some authentication credentials associated > with the session. > > When I have some form of access failure (e.g., through my own code checking > some property of a user and a page), I can display an error page from which > I can redirect to the index.jsp. However, when I go from there to the > secure area again, the existing authentication credentials are still > associated with the session. > > To force the creation of a new set of authentication credentials I added > <% > if (! session.isNew() ) > { > session.invalidate(); > %> > <rsp:sendRedirect> > <rsp:encodeRedirectUrl>/scoutgroup/index.jsp</rsp:encodeRedirectUrl> > </rsp:sendRedirect> > <% > } > Class.forName("org.gjt.mm.mysql.Driver"); > %> > to the top of index.jsp. Now, each time I try to access the secure area > (using <a href=/members/index.jsp>) from index.jsp, I get prompted for a new > userid and password via my login form - at least that's what happens with > netscape. IE firstly complains (http error 302 - resource temporarily > relocated) each time it tries to execute the sendRedirect but does so after > an error dialogue and a click of the refresh button but then tells me it > cannot find the secure page even though I have > <url-pattern>/members/*</url-pattern> > </web-resource-collection> > <auth-constraint> > <role-name>member</role-name> > </auth-constraint> > <user-data-constraint> > <transport-guarantee>CONFIDENTIAL</transport-guarantee> > </user-data-constraint> > in my web.xml. > Before failing on the secure web page, the status bar shows a message > "redirecting to https://localhost:8443/..."; and I get a warning about > accessing secure pages and have my SSL certificate challenged but I never > reach the login page. > > If I enter the full path (https://localhost:8443/....) of the secure area in > the address box I am driven through the proper authentication path and, > thereafter, remain in an https session while I navigate back and forth > between the secure and public areas. Each pass through the index.jsp forces > a new logon. > > I'm confused!! Why does Netscape work when IE won't? How can I downgrade > my session from https to http when I return to the public area? > > -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] Behalf Of Bill Barker > Sent: Tuesday, 29 July 2003 13:14 > To: [EMAIL PROTECTED] > Subject: Re: HTTPS session strangeness with Tomcat 4.0.6 > > > Filip is correct. In more detail, what is happening is that you establish a > session with your HTTPS login page. When you drop out of HTTPS, you > establish a new session under HTTP. Now when you re-login, your login page > uses the HTTP-established session, so it is still available to your HTTP > pages. > > The only way to "fix" this is to download the source distro, and modify the > Tomcat code yourself and re-compile. > > "Filip Hanik" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > when a session is established in HTTPS, the session will not work for > HTTP, > > it is a security thing. > > > > If the session is established in HTTP, it will work for both HTTPS and > HTTP > > I believe > > > > Filip > > > > > -----Original Message----- > > > From: Dan Lipofsky [mailto:[EMAIL PROTECTED] > > > Sent: Monday, July 28, 2003 4:54 PM > > > To: Tomcat Users List > > > Subject: Re: HTTPS session strangeness with Tomcat 4.0.6 > > > > > > > > > No. I just tried with Netscape 7.1, IE 5.5, and IE 6.0. > > > Same results for all. It's definitely a Tomcat thing. > > > - Dan > > > > > > > Dan, > > > > > > > > Does it matter which browser you use? I am experiencing (so far > without > > > > resolution) problems invalidating and re-establishing sessions and > > > > refreshing pages based on session status when I use IE but have the > same > > > > pages operate perfectly under NetScape. > > > > > > > > Murray > > > > -----Original Message----- > > > > From: Dan Lipofsky [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, 29 July 2003 06:54 > > > > To: [EMAIL PROTECTED] > > > > Subject: HTTPS session strangeness with Tomcat 4.0.6 > > > > > > > > > > > > I have a login JSP that does a session.setAttribute and all > > > > subsequent pages do a session.getAttribute to ensure the > > > > user is logged in. The login page uses HTTPS and then > > > > redirects to HTTP for subsequent pages. This worked in > > > > Tomcat 3.2.4 but fails in Tomcat 4.0.6, 4.1.24, and 5 alpha. > > > > BUT THE WAY IT FAILS IS PARTICULARLY BIZARRE - it will fail > > > > the first time but work the second time. This is very > > > > consistent. Below are 2 extremely simple JSPs that demo the > > > > problem. The first only sets the attribute and provides a > > > > link to the second. The second displays the attribute. The > > > > first time through it will say "TEST=null". If you then hit > > > > the back button and refresh the first page and click next > > > > again it will say "TEST=TEST_VAL" like it should > > > > > > > > > > > > *** First JSP: https://www3.nuserve.com:8011/testS1.jsp *** > > > > > > > > <% > > > > System.out.println("Setting TEST_KEY=TEST_VAL"); > > > > session.setAttribute("TEST_KEY","TEST_VAL"); > > > > %> > > > > <a href="http://www3.nuserve.com:8010/testS2.jsp";>next</a> > > > > > > > > > > > > *** Second JSP: http://www3.nuserve.com:8010/testS2.jsp *** > > > > > > > > TEST=<%=session.getAttribute("TEST_KEY")%> > > > > > > > > > > > > Does anyone have an idea what causes this or how to fix it? > > > > Thanks, > > > > Dan > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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]
