wood burning stoves 2.0*
The moose likes Servlets and the fly likes sharing session state between https and http Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "sharing session state between https and http" Watch "sharing session state between https and http" New topic
Author

sharing session state between https and http

Jonh Smith
Ranch Hand

Joined: Mar 18, 2010
Posts: 39
Is there any way to share a httpsession between the confidential and the non confidential parts of a web-app, without resorting to url rewriting ?

The question relates to the fact that whenever I do sendRedirect to an http servlet from inside an https servlet (one having a url with the CONFIDENTIAL transport-guarantee) , any session that I created inside the https servlet is not propagated, since the browser does not send any jsessionid generated by the https servlet (with request.getSession) to the http servlet in the same app, either due to the fact that the cookie is set with the Secure attribute in the first place or due to the http and https running in different ports not being recognized as the same app by the browser, or both.

More generically, what is the standard way to make a user access non-confidential content only as a securely (confidentialy) authenticated user ?

Thanks.
Jonh Smith
Ranch Hand

Joined: Mar 18, 2010
Posts: 39
Just to share, the solution i came up with was to manage my own authentication information in a hashmap stored as a servlet context attribute.

1. https servlet trigers the container login prompt,
2. login ok => https servlet creates a UUID and stores it in that hashmap as the key to an UserInfo instance containing : the username (getUserPrincipal), role (isUserInRole(...)) and the uuid itself.
3. https redirects to http frontcontroller, having the uuid attached as parameter.
4. http frontcontroller reads the uuid parameter, retrieves the respective Userinfo from the global hashmap (stored in servletcontext) and if it finds it, creates a new session (request.getSession()) and stores this Userinfo as an attribute "uuid" of that session, to enable programatic authorization further on.
5. front controller forwards to pages inside WEB-INF, hence not directly accessible by the client.

the lifecycle of the userinfo in the hashmap is connected with that of the http session because I created a HttpSessionListener that overrides the sessionDestroyed method to remove the entry in the hashmap having the same uuid stored in the session to destroy.

there is also a ServletContextListener to create the UserInfo hashmap and insert it as an attribute of the servlet context.

So, that was my first solution. Anyway, I ended up concluding that the info I was planning to provide via http, is actually sensitive enough to justify the ssl overhead... :)
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Most servers either share by default, or can be configured to share, session data between HTTP and HTTPS.

(At least that's been my experience--I've almost never had to do anything, and certainly nothing like what you've described.)
Jonh Smith
Ranch Hand

Joined: Mar 18, 2010
Posts: 39
Thanks David! I will look into it.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: sharing session state between https and http