Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      all, tested with GlassFish Server Open Source Edition 3.2-SNAPSHOT (re-continuous), Build #9159 (14.08.2011 23:30:35), Revision: 48776

      Description

      fix in GLASSFISH-17131 made now HTTP->HTTPS ccle working, but in HTTPS->HTTP traversal jsessionId is still lost; Can be viewed by the example app in GLASSFISH-17131;

        Activity

        KBachl created issue -
        Hide
        Shing Wai Chan added a comment -

        Per discussion in http://java.net/jira/browse/GLASSFISH-17131 and the original description, I think you mean the scenario of http to https.

        For https to http, there is a concern of exposing the cookies through url. That is why I do not encode the jsessionId in this case.

        Show
        Shing Wai Chan added a comment - Per discussion in http://java.net/jira/browse/GLASSFISH-17131 and the original description, I think you mean the scenario of http to https. For https to http, there is a concern of exposing the cookies through url. That is why I do not encode the jsessionId in this case.
        Hide
        KBachl added a comment -

        Hello Shing Wai,

        you need to differ if the session was created in HTTP (1 = insecure session) or HTTPS (2 = secure session).

        In case of HTTP created session (1):

        -> user gets jsessionId, he may move on to https and also leave https to http side without loosing the session

        In case of HTTPS created session (2):

        -> user gets jsessionId, he may not leave from HTTPS and will loose his session there;

        Currently any session traversal from HTTPS to HTTP will loose, independent of when it was created. The above described behaviour is also implemented exactly that way in other containers like Tomcat, Jetty and JBOSS as it immitates the behaviour from browser cookies. Those are only marked secure in case they were created within HTTPS space.

        Currently one can't rely on glassfish URL rewriting as it will loose any insecure sessions in case of a HTTPS->HTTP traversal.

        If you have any questions left or don't think that my arguments are valid just tell me

        Best

        Show
        KBachl added a comment - Hello Shing Wai, you need to differ if the session was created in HTTP (1 = insecure session) or HTTPS (2 = secure session). In case of HTTP created session (1): -> user gets jsessionId, he may move on to https and also leave https to http side without loosing the session In case of HTTPS created session (2): -> user gets jsessionId, he may not leave from HTTPS and will loose his session there; Currently any session traversal from HTTPS to HTTP will loose, independent of when it was created. The above described behaviour is also implemented exactly that way in other containers like Tomcat, Jetty and JBOSS as it immitates the behaviour from browser cookies. Those are only marked secure in case they were created within HTTPS space. Currently one can't rely on glassfish URL rewriting as it will loose any insecure sessions in case of a HTTPS->HTTP traversal. If you have any questions left or don't think that my arguments are valid just tell me Best
        Shing Wai Chan made changes -
        Field Original Value New Value
        Assignee Nazrul [ ai109478 ] Shing Wai Chan [ swchan2 ]
        Hide
        Shing Wai Chan added a comment -

        I have considered this scenario before. The question is how we know whether a session is secure (from https) or not. The information is not exposed from HttpSession.
        One may require an interface change, at least the internal one, in order to achieve this.
        Need further investigation.

        Show
        Shing Wai Chan added a comment - I have considered this scenario before. The question is how we know whether a session is secure (from https) or not. The information is not exposed from HttpSession. One may require an interface change, at least the internal one, in order to achieve this. Need further investigation.
        Shing Wai Chan made changes -
        Summary reOpen of GLASSFISH-17131 jsessionId is lost while redirecting from https to http
        Hide
        KBachl added a comment -

        Hello Shing Wai,

        regarding the differentation. Why don't you introduce a flag within the session, stating "boolean isSecureSession = false" and only set this true when session is created within HTTPS space. Then in case of HTTPS -> HTTP change you only look if the session is Secure and act accordingly.

        Show
        KBachl added a comment - Hello Shing Wai, regarding the differentation. Why don't you introduce a flag within the session, stating "boolean isSecureSession = false" and only set this true when session is created within HTTPS space. Then in case of HTTPS -> HTTP change you only look if the session is Secure and act accordingly.
        Hide
        Shing Wai Chan added a comment -

        This will workaround the issue. But then user can modified the flag in session.

        Show
        Shing Wai Chan added a comment - This will workaround the issue. But then user can modified the flag in session.
        Hide
        Shing Wai Chan added a comment -

        The https issue can be resolved by adding secure attribute in internal Session interface.
        Then we will face the issue as in GLASSFISH-17131.
        In that case, a different port number (with same or different schema) is not enough to tell whether it is a redirect within the same server. In fact, it may be different server.

        We will mark this as a duplicate of GLASSFISH-17131.

        Show
        Shing Wai Chan added a comment - The https issue can be resolved by adding secure attribute in internal Session interface. Then we will face the issue as in GLASSFISH-17131 . In that case, a different port number (with same or different schema) is not enough to tell whether it is a redirect within the same server. In fact, it may be different server. We will mark this as a duplicate of GLASSFISH-17131 .
        Shing Wai Chan made changes -
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Duplicate [ 3 ]

          People

          • Assignee:
            Shing Wai Chan
            Reporter:
            KBachl
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: