• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

sharing session state between https and http

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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... :)
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks David! I will look into it.
reply
    Bookmark Topic Watch Topic
  • New Topic