Topic
  • 8 replies
  • Latest Post - ‏2013-12-17T15:35:00Z by MyScreen2
MyScreen2
MyScreen2
41 Posts

Pinned topic Migrating a WAS 8.0 war to Liberty Profile 8.5.5.1 - Session Mgmt

‏2013-12-14T21:11:22Z |

I have a war file installed in WAS 8.0 and I have to make the following config change in the admin console.  To get the I hyperlink on:

1) Application 'X'

2) Manage Modules

3) Module X

4) Session Management

Then I change the following settings:

1) Check 'Override session management'

2) Uncheck 'Enable Cookies'

3) Set'Session Timeout to 'No timeout'

 

I have deployed the same war file into liberty and have it running, but I want to make set same values.  I tried adding the following line to my server.xml file but it does not make a difference:

 

    <httpsession cookiesEnabled="false" invalidationTimeout="0" />
 

Does anyone see the mistake I made or any advice on how to do this?  Any help would be greatly appreciated!

 

  • MyScreen2
    MyScreen2
    41 Posts
    ACCEPTED ANSWER

    Re: Migrating a WAS 8.0 war to Liberty Profile 8.5.5.1 - Session Mgmt

    ‏2013-12-17T15:35:00Z  
    • bergmark
    • ‏2013-12-16T19:49:17Z

    I believe that 'override' setting is probably you explicitly stating that you want to override the server wide session settings in this particular application.

    Its not entirely clear to me even in Full Profile how you are able to get two distinct sessions in the same web application for the same browser, especially given the setting you mentioned seems to prevent all HttpSession cookies. Are you really talking about HttpSessions (HttpServletRequest.getSession) or do you mean some kind of user authentication?

     

    I found out what the problem was, but I am embarrassed to say...

     

    I was actually working on some other part of the migration when I happened to notice that the "httpsession" did not have the capital "S".  I changed that and my problem went away!

     

    Thanks again so much for the help - I did learn several more things from your comments.  This is a great forum.

  • bergmark
    bergmark
    42 Posts

    Re: Migrating a WAS 8.0 war to Liberty Profile 8.5.5.1 - Session Mgmt

    ‏2013-12-16T15:36:07Z  

    When you say it does not make a difference, do you mean that the session cookie is still sent to the browser after adding the snippet above to your server.xml?

  • MyScreen2
    MyScreen2
    41 Posts

    Re: Migrating a WAS 8.0 war to Liberty Profile 8.5.5.1 - Session Mgmt

    ‏2013-12-16T16:06:41Z  
    • bergmark
    • ‏2013-12-16T15:36:07Z

    When you say it does not make a difference, do you mean that the session cookie is still sent to the browser after adding the snippet above to your server.xml?

    By 'not making a difference' I mean the behavior I am trying to avoid still exists.  I do not exactly know what the three settings in WAS 8.0 do other than it allows our application to work (specifically the cookies setting).  When I loaded the same war file into Liberty I saw the same bad behavior at runtime so I was trying to set the same values in Liberty as in WAS 8.0.

     

    In the WAS Console there are two 'Session Management' links for an app - one under the App itself and one under the Module of the App.  We have to change the latter to fix our problem in WAS 8.0.  In the server/xml line above there is mention of either level (app versus module), nor do I know if there should be.  Seems like there should be but I do not know how much of this works.

  • bergmark
    bergmark
    42 Posts

    Re: Migrating a WAS 8.0 war to Liberty Profile 8.5.5.1 - Session Mgmt

    ‏2013-12-16T16:19:44Z  

    By 'not making a difference' I mean the behavior I am trying to avoid still exists.  I do not exactly know what the three settings in WAS 8.0 do other than it allows our application to work (specifically the cookies setting).  When I loaded the same war file into Liberty I saw the same bad behavior at runtime so I was trying to set the same values in Liberty as in WAS 8.0.

     

    In the WAS Console there are two 'Session Management' links for an app - one under the App itself and one under the Module of the App.  We have to change the latter to fix our problem in WAS 8.0.  In the server/xml line above there is mention of either level (app versus module), nor do I know if there should be.  Seems like there should be but I do not know how much of this works.

    What behavior are you trying to avoid?  As I understand that property, it should prevent the session cookie being sent to the browser, which effectively means subsequent requests from that browser will not be associated with the same session unless you are using some other mechanism (URL rewriting for example).

    Currently the liberty server.xml configuration does not provide a way to modify the session management on a per-application basis.

  • MyScreen2
    MyScreen2
    41 Posts

    Re: Migrating a WAS 8.0 war to Liberty Profile 8.5.5.1 - Session Mgmt

    ‏2013-12-16T18:21:42Z  
    • bergmark
    • ‏2013-12-16T16:19:44Z

    What behavior are you trying to avoid?  As I understand that property, it should prevent the session cookie being sent to the browser, which effectively means subsequent requests from that browser will not be associated with the same session unless you are using some other mechanism (URL rewriting for example).

    Currently the liberty server.xml configuration does not provide a way to modify the session management on a per-application basis.

    First, thanks for your replies!

    When a user is signed onto our application, we have a button they can press to start a new session which automatically logs them in under a new session id.  We need these two (or more sessions) to be independent of one another.  With Liberty now, the 'new' session will appear but it is not truly new, and when the user logs off this 'new' session and then tries to do something in the original one, they are immediately bumped off because the sessions were actually the same.

    Maybe we cannot user Liberty until this is supported.

  • MyScreen2
    MyScreen2
    41 Posts

    Re: Migrating a WAS 8.0 war to Liberty Profile 8.5.5.1 - Session Mgmt

    ‏2013-12-16T19:23:59Z  
    • bergmark
    • ‏2013-12-16T16:19:44Z

    What behavior are you trying to avoid?  As I understand that property, it should prevent the session cookie being sent to the browser, which effectively means subsequent requests from that browser will not be associated with the same session unless you are using some other mechanism (URL rewriting for example).

    Currently the liberty server.xml configuration does not provide a way to modify the session management on a per-application basis.

    Your last comment said Liberty cannot modify the session mgmt. on a per application basis, and I am OK with that - the only application running in the server is ours.  But it still seems like my httpsession line in the server.xml is not working for the enablecookies.

    One question.  In WAS 8 we check the top box to 'override' the settings, but in Liberty there is no entry for that.  Do you know if the line itself represents that checkbox in WAS8.0?

  • bergmark
    bergmark
    42 Posts

    Re: Migrating a WAS 8.0 war to Liberty Profile 8.5.5.1 - Session Mgmt

    ‏2013-12-16T19:49:17Z  

    Your last comment said Liberty cannot modify the session mgmt. on a per application basis, and I am OK with that - the only application running in the server is ours.  But it still seems like my httpsession line in the server.xml is not working for the enablecookies.

    One question.  In WAS 8 we check the top box to 'override' the settings, but in Liberty there is no entry for that.  Do you know if the line itself represents that checkbox in WAS8.0?

    I believe that 'override' setting is probably you explicitly stating that you want to override the server wide session settings in this particular application.

    Its not entirely clear to me even in Full Profile how you are able to get two distinct sessions in the same web application for the same browser, especially given the setting you mentioned seems to prevent all HttpSession cookies. Are you really talking about HttpSessions (HttpServletRequest.getSession) or do you mean some kind of user authentication?

     

  • MyScreen2
    MyScreen2
    41 Posts

    Re: Migrating a WAS 8.0 war to Liberty Profile 8.5.5.1 - Session Mgmt

    ‏2013-12-16T20:03:46Z  
    • bergmark
    • ‏2013-12-16T19:49:17Z

    I believe that 'override' setting is probably you explicitly stating that you want to override the server wide session settings in this particular application.

    Its not entirely clear to me even in Full Profile how you are able to get two distinct sessions in the same web application for the same browser, especially given the setting you mentioned seems to prevent all HttpSession cookies. Are you really talking about HttpSessions (HttpServletRequest.getSession) or do you mean some kind of user authentication?

     

    Actually, when the user is in our app and they click the button, a new browser is opened, the user is automatically authenticated, and now the user has two browsers open in our app with two different session ids so that they can run them independently.  And when they sign off one of them the other is still active.

    Maybe this is really a problem with how IE opens the new browser - it shares the session id between them.  That is unless, in WAS 8.0, we make these changes.

    To answer your question, I would say that we are using the getSession.  We us a tool that generates the Java for us, but the command we use is Session.Get or Session.Set or Session.Destroy.

  • MyScreen2
    MyScreen2
    41 Posts

    Re: Migrating a WAS 8.0 war to Liberty Profile 8.5.5.1 - Session Mgmt

    ‏2013-12-17T15:35:00Z  
    • bergmark
    • ‏2013-12-16T19:49:17Z

    I believe that 'override' setting is probably you explicitly stating that you want to override the server wide session settings in this particular application.

    Its not entirely clear to me even in Full Profile how you are able to get two distinct sessions in the same web application for the same browser, especially given the setting you mentioned seems to prevent all HttpSession cookies. Are you really talking about HttpSessions (HttpServletRequest.getSession) or do you mean some kind of user authentication?

     

    I found out what the problem was, but I am embarrassed to say...

     

    I was actually working on some other part of the migration when I happened to notice that the "httpsession" did not have the capital "S".  I changed that and my problem went away!

     

    Thanks again so much for the help - I did learn several more things from your comments.  This is a great forum.