• Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • JWS 3.0.3 DR1
    • JWS 3.0.2 ER1
    • tomcat7
    • None

            [JWS-271] User submitted session ID

            Since the problem described in this issue should be resolved in a recent advisory, it has been closed.

            For information on the advisory, and where to find the updated files, follow the link below.

            If the solution does not work for you, open a new bug report.
            https://rhn.redhat.com/errata/RHSA-2016-1089.html

            Errata Tool added a comment - Since the problem described in this issue should be resolved in a recent advisory, it has been closed. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-1089.html

            The behavior is correct. Session IDs can be shared across applications, but the actual session cannot. See section 7.3 from the Servlet 3.0 Spec regarding Session Scope:

            "HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container."

            Coty Sutherland added a comment - The behavior is correct. Session IDs can be shared across applications, but the actual session cannot. See section 7.3 from the Servlet 3.0 Spec regarding Session Scope: "HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container."

            Fair point, thanks...

            Correct me again but this doesn't looks correct. "test2" should take session from "test" application not just take its session id and create new session with it,
            am i right?

            [root@localhost tomcat7]# curl 127.0.0.1:8080/test/test.jsp -c cookie.txt -b cookie.txt -i
            HTTP/1.1 200 OK
            Server: Apache-Coyote/1.1
            Set-Cookie: JSESSIONID=71DBF239043B116B71FDBFB149AAB788; Path=/; HttpOnly
            Content-Type: text/html;charset=ISO-8859-1
            Content-Length: 39
            Date: Tue, 09 Feb 2016 10:05:23 GMT
            
            71DBF239043B116B71FDBFB149AAB788 true
            
            [root@localhost tomcat7]# curl 127.0.0.1:8080/test2/test.jsp -c cookie.txt -b cookie.txt -i
            HTTP/1.1 200 OK
            Server: Apache-Coyote/1.1
            Set-Cookie: JSESSIONID=71DBF239043B116B71FDBFB149AAB788; Path=/; HttpOnly
            Content-Type: text/html;charset=ISO-8859-1
            Content-Length: 43
            Date: Tue, 09 Feb 2016 10:05:31 GMT
            
            71DBF239043B116B71FDBFB149AAB788 true null
            [root@localhost tomcat7]# cat cookie.txt 
            # Netscape HTTP Cookie File
            # http://curl.haxx.se/docs/http-cookies.html
            # This file was generated by libcurl! Edit at your own risk.
            
            #HttpOnly_127.0.0.1	FALSE	/	FALSE	0	JSESSIONID	71DBF239043B116B71FDBFB149AAB788
            [root@localhost tomcat7]# cat webapps/test/test.jsp 
            <% out.print( session.getId() + " " + session.isNew() );%>
            <% session.setAttribute("Devil", 666);%>
            [root@localhost tomcat7]# cat webapps/test2/test.jsp 
            <% out.print( session.getId() + " "  + session.isNew() + " " + session.getAttribute("Devil") ); %>
            

            Bogdan Sikora (Inactive) added a comment - Fair point, thanks... Correct me again but this doesn't looks correct. "test2" should take session from "test" application not just take its session id and create new session with it, am i right? [root@localhost tomcat7]# curl 127.0.0.1:8080/test/test.jsp -c cookie.txt -b cookie.txt -i HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=71DBF239043B116B71FDBFB149AAB788; Path=/; HttpOnly Content-Type: text/html;charset=ISO-8859-1 Content-Length: 39 Date: Tue, 09 Feb 2016 10:05:23 GMT 71DBF239043B116B71FDBFB149AAB788 true [root@localhost tomcat7]# curl 127.0.0.1:8080/test2/test.jsp -c cookie.txt -b cookie.txt -i HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=71DBF239043B116B71FDBFB149AAB788; Path=/; HttpOnly Content-Type: text/html;charset=ISO-8859-1 Content-Length: 43 Date: Tue, 09 Feb 2016 10:05:31 GMT 71DBF239043B116B71FDBFB149AAB788 true null [root@localhost tomcat7]# cat cookie.txt # Netscape HTTP Cookie File # http://curl.haxx.se/docs/http-cookies.html # This file was generated by libcurl! Edit at your own risk. #HttpOnly_127.0.0.1 FALSE / FALSE 0 JSESSIONID 71DBF239043B116B71FDBFB149AAB788 [root@localhost tomcat7]# cat webapps/test/test.jsp <% out.print( session.getId() + " " + session.isNew() );%> <% session.setAttribute("Devil", 666);%> [root@localhost tomcat7]# cat webapps/test2/test.jsp <% out.print( session.getId() + " " + session.isNew() + " " + session.getAttribute("Devil") ); %>

            bsikora, that behavior looks correct to me. The fact that you are still able to reuse the session after tomcat has been restarted is because active sessions are persisted to disk by the manager and then reloaded; see here for more info on that. Additionally, the session validation only checks to ensure that the session already exists in at least one other application before it can be used. If the session does not exist, then tomcat will provide a new session to the user. The exact context in which this should occur is now documented here under the `validateClientProvidedNewSessionId` attribute.

            Let me know if I can clarify any further or if your interpretation of the docs are different.

            Coty Sutherland added a comment - bsikora , that behavior looks correct to me. The fact that you are still able to reuse the session after tomcat has been restarted is because active sessions are persisted to disk by the manager and then reloaded; see here for more info on that. Additionally, the session validation only checks to ensure that the session already exists in at least one other application before it can be used. If the session does not exist, then tomcat will provide a new session to the user. The exact context in which this should occur is now documented here under the `validateClientProvidedNewSessionId` attribute. Let me know if I can clarify any further or if your interpretation of the docs are different.

            3.0.3-DR1

            <Context sessionCookiePath="/">

            [root@localhost tomcat7]# curl 127.0.0.1:8080/test/test.jsp -c cookie.txt -b cookie.txt -i
            HTTP/1.1 200 OK
            Server: Apache-Coyote/1.1
            Content-Type: text/html;charset=ISO-8859-1
            Content-Length: 38
            Date: Mon, 08 Feb 2016 11:25:28 GMT
            
            98BA50076BD02D4A41E65A756D19145Etrue
            [root@localhost tomcat7]# ./bin/shutdown.sh 
            Using CATALINA_BASE:   /opt/jws-3.0/tomcat7
            Using CATALINA_HOME:   /opt/jws-3.0/tomcat7
            Using CATALINA_TMPDIR: /opt/jws-3.0/tomcat7/temp
            Using JRE_HOME:        /usr
            Using CLASSPATH:       /opt/jws-3.0/tomcat7/bin/bootstrap.jar:/opt/jws-3.0/tomcat7/bin/tomcat-juli.jar
            [root@localhost tomcat7]# ./bin/startup.sh 
            Using CATALINA_BASE:   /opt/jws-3.0/tomcat7
            Using CATALINA_HOME:   /opt/jws-3.0/tomcat7
            Using CATALINA_TMPDIR: /opt/jws-3.0/tomcat7/temp
            Using JRE_HOME:        /usr
            Using CLASSPATH:       /opt/jws-3.0/tomcat7/bin/bootstrap.jar:/opt/jws-3.0/tomcat7/bin/tomcat-juli.jar
            Tomcat started.
            [root@localhost tomcat7]# curl 127.0.0.1:8080/test/test.jsp -c cookie.txt -b cookie.txt -i
            HTTP/1.1 200 OK
            Server: Apache-Coyote/1.1
            Content-Type: text/html;charset=ISO-8859-1
            Content-Length: 38
            Date: Mon, 08 Feb 2016 11:25:47 GMT
            
            98BA50076BD02D4A41E65A756D19145Efalse
            
            [root@localhost tomcat7]# cat webapps/test/test.jsp
            <% out.print( session.getId() + session.isNew() ); %>
            

            that's not correct if i understand it correctly, right?

            Bogdan Sikora (Inactive) added a comment - 3.0.3-DR1 <Context sessionCookiePath="/"> [root@localhost tomcat7]# curl 127.0.0.1:8080/test/test.jsp -c cookie.txt -b cookie.txt -i HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Content-Length: 38 Date: Mon, 08 Feb 2016 11:25:28 GMT 98BA50076BD02D4A41E65A756D19145Etrue [root@localhost tomcat7]# ./bin/shutdown.sh Using CATALINA_BASE: /opt/jws-3.0/tomcat7 Using CATALINA_HOME: /opt/jws-3.0/tomcat7 Using CATALINA_TMPDIR: /opt/jws-3.0/tomcat7/temp Using JRE_HOME: /usr Using CLASSPATH: /opt/jws-3.0/tomcat7/bin/bootstrap.jar:/opt/jws-3.0/tomcat7/bin/tomcat-juli.jar [root@localhost tomcat7]# ./bin/startup.sh Using CATALINA_BASE: /opt/jws-3.0/tomcat7 Using CATALINA_HOME: /opt/jws-3.0/tomcat7 Using CATALINA_TMPDIR: /opt/jws-3.0/tomcat7/temp Using JRE_HOME: /usr Using CLASSPATH: /opt/jws-3.0/tomcat7/bin/bootstrap.jar:/opt/jws-3.0/tomcat7/bin/tomcat-juli.jar Tomcat started. [root@localhost tomcat7]# curl 127.0.0.1:8080/test/test.jsp -c cookie.txt -b cookie.txt -i HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=ISO-8859-1 Content-Length: 38 Date: Mon, 08 Feb 2016 11:25:47 GMT 98BA50076BD02D4A41E65A756D19145Efalse [root@localhost tomcat7]# cat webapps/test/test.jsp <% out.print( session.getId() + session.isNew() ); %> that's not correct if i understand it correctly, right?

            Adding a blocking link to ensure that this gets fixed by the rebase.

            Coty Sutherland added a comment - Adding a blocking link to ensure that this gets fixed by the rebase.

            7.0.59-43_patch_01

            Marking this as resolved with no fixVersion because it won't be fixed in 3.0.2 unless we have another build. It is now fixed in 3.0.x.

            Coty Sutherland added a comment - 7.0.59-43_patch_01 Marking this as resolved with no fixVersion because it won't be fixed in 3.0.2 unless we have another build. It is now fixed in 3.0.x.

            Coty Sutherland added a comment - - edited

            Yes, tomcat8 is also affected. Remy has reopened JWS-272 and added the necessary fix for it also. I'll be patching them both shortly.

            Coty Sutherland added a comment - - edited Yes, tomcat8 is also affected. Remy has reopened JWS-272 and added the necessary fix for it also. I'll be patching them both shortly.

            Just to be sure, same promlem occurs in https://issues.jboss.org/browse/JWS-272, aka tomcat 8

            Bogdan Sikora (Inactive) added a comment - Just to be sure, same promlem occurs in https://issues.jboss.org/browse/JWS-272 , aka tomcat 8

            Hm...not sure how I missed that. I thought it was working :/ but now I think I found a bug in the patch. Let me check on it with Remy and get back to you.

            Coty Sutherland added a comment - Hm...not sure how I missed that. I thought it was working :/ but now I think I found a bug in the patch. Let me check on it with Remy and get back to you.

              rhn-support-csutherl Coty Sutherland
              rhn-support-csutherl Coty Sutherland
              Bogdan Sikora Bogdan Sikora (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: