Re: [enhydra] Problem with ServerPageRedirectException's + SessionEncodeUrlState="always"

Hi,

You are right, ServerPageRedirectException does not maintain the session when cookies are disabled (on browser side or by setting SessionManager.SessionEncodeUrlState parameter to allways)! 

This bug is present in Enhydra 5.x (not in Enhydra 6.x) releases.

Problem seems to be in 'com.lutris.appserver.server.StandardAppUtil.getRequestSession(HttpPresentationComms comms)' static method implementation. I've attached modified implementation (and implementation differences) file(s) for you.

Note that we have stopped further development of Enhydra 5 releases. Therefore, I'm suggesting migration to Enhydra 6.

Regards,
    Slobodan Vujasinovic
Enhydra Development Team
  ----- Original Message ----- 
  From: Michael Strapp 
  To: Enhydra Mailing List 
  Sent: Monday, July 04, 2005 11:49 PM
  Subject: [enhydra] Problem with ServerPageRedirectException's + SessionEncodeUrlState="always"


  Hi all,
      I have encountered a problem under both Enhydra 5.1 and Enhydra 5.4 (and it might be present under Enhydra 6.x), that a ServerPageRedirectException does not maintain the session when cookies on the browser side are disabled, which causes Enhydra to switch to using URL encoding to keep track of the session key - or if you set the SessionManager.SessionEncodeUrlState setting for the Enhydra app to "always".  I wrote some test code (calling the comms.session.getSessionKey() and and comms.request.getRequestURI() methods), and confirmed that the URL contains the ';jsessionid=' string is present, and the session key is maintained, for the presentation object that throws the ServerPageRedirectException - but for the presentation object that Enhydra launches in response to the ServerPageRedirectException, the URL does not contain the ';jsessionid=' string, and a new session is started (with a new session key).
   
      I've never examined the Enhydra source code that processes requests or redirections, and I wouldn't really know where to look for the source of this problem - can someone investigate and see what they can find?
   
  Thanks in advance,
  Michael Strapp.

FILE COMPARISON
Produced: 7/5/2005 10:38:47 AM

Mode:  Just Differences

Left file: StandardAppUtil.java     
Right file: New implementation: StandardAppUtil.java

R247             if (!sessionManager.getEncodeUrlState().equalsIgnoreCase(StandardSessionManager.ENCODE_URL_ALWAYS)) {
------------------------------------------------------------------------
------------------------------------------------------------------------
L254             if (!sessionManager.getEncodeUrlState().equalsIgnoreCase(StandardSessionManager.ENCODE_URL_ALWAYS)) {
------------------------------------------------------------------------
------------------------------------------------------------------------
R281         HttpServletRequest servletRequest = comms.request.getHttpServletRequest();
             sessionKey = servletRequest.getRequestedSessionId();
             if (sessionKey != null) {
               if (servletRequest.isRequestedSessionIdFromURL()) {
                 comms.request.setRequestedSessionIdFromUrl(true);
                 comms.request.setRequestedSessionIdFromCookie(false);
                 comms.response.setSessionIdEncodeUrlRequired(true);
                 comms.response.setSessionIdCookieRequired(false);
               }
             }
             else {
------------------------------------------------------------------------
------------------------------------------------------------------------
L299                 }
                 }
R310                 }
                 }
        }
------------------------------------------------------------------------

--
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws