Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-959

XMLUI login failure when using Tomcat 7.0.16

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.2
    • Fix Version/s: 1.8.0
    • Component/s: XMLUI
    • Labels:
      None
    • Environment:
      Based on discussion on 'dspace-tech', seems to affect the following browsers:
      * IE
      * Chrome
      * Safari
      * Opera
    • Attachments:
      3
    • Comments:
      18
    • Documentation Status:
      Not Required

      Attachments

        Activity

        Hide
        tdonohue Tim Donohue added a comment -

        Ok, I feel like I'm now 95% of the way, but I'm now a bit "stuck" and I may need more eyes/suggestions.

        What I've discovered is the following:

        However, this 'redirect' fix doesn't quite work yet, as XMLUI seems to be adding its own Response Headers. I'm not sure if it is Cocoon, but something keeps adding in a 'Set-Cookie' header which I cannot seem to override. Here's what the Response Headers look like for JSPUI vs XMLUI

        In JSPUI, if you access /jspui (no trailing slash), you'll get a response like:

        HTTP/1.1 302 Moved Temporarily
        Server: Apache-Coyote/1.1
        Location: http://localhost:8080/dspace-jspui/
        Transfer-Encoding: chunked
        Date: Tue, 27 Sep 2011 17:36:42 GMT

        However, in XMLUI, with my above patch in place, an access to /xmlui (no trailing slash) ends up with a slightly different response:

        HTTP/1.1 302 Moved Temporarily
        Server: Apache-Coyote/1.1
        Set-Cookie: JSESSIONID=78BBF6371FC69551818789FFC7806B6D; Path=/dspace-xmlui/; HttpOnly
        Location: http://localhost:8080/dspace-xmlui/
        Content-Length: 0
        Date: Tue, 27 Sep 2011 18:02:33 GMT

        The main difference between the two responses is that the XMLUI always responds with a 'Set-Cookie' which clears your old session cookie and replaces it with a new one. This is the underlying cause of the 'disappearing session' if you access the main XMLUI homepage without a trailing slash.

        If we can figure out a way to get the XMLUI/Cocoon to stop creating & setting a new Cookie, it should fix the issue completely (like in the JSPUI). But, at this point, I'm at a loss as to how to do that, since I'm not sure what is setting that Cookie.

        In the meantime, the above patch brings us about 95% of the way there. The user's login & session is kept in most every scenario. The only way the session is still "lost" is if the user manually changes the URL path in their browser to the XMLUI homepage without a trailing slash (e.g. http://localhost:8080/xmlui). But, it is possible to even fix that scenario by changing your Tomcat 7 configuration to sessionCookiePathUsesTrailingSlash='false'.

        Show
        tdonohue Tim Donohue added a comment - Ok, I feel like I'm now 95% of the way, but I'm now a bit "stuck" and I may need more eyes/suggestions. What I've discovered is the following: The JSPUI seems to avoid this issue because it always does a 302 redirect of the URL http://localhost:8080/jspui to http://localhost:8080/jspui/ (with trailing slash) I can setup the XMLUI to do a similar auto-redirect (see attached patch: Tim- DS-959 .patch). With this patch it will always do a 302 redirect of the URL http://localhost:8080/xmlui to http://localhost:8080/xmlui/ (with trailing slash) However, this 'redirect' fix doesn't quite work yet, as XMLUI seems to be adding its own Response Headers. I'm not sure if it is Cocoon, but something keeps adding in a 'Set-Cookie' header which I cannot seem to override. Here's what the Response Headers look like for JSPUI vs XMLUI In JSPUI, if you access /jspui (no trailing slash), you'll get a response like: HTTP/1.1 302 Moved Temporarily Server: Apache-Coyote/1.1 Location: http://localhost:8080/dspace-jspui/ Transfer-Encoding: chunked Date: Tue, 27 Sep 2011 17:36:42 GMT However, in XMLUI, with my above patch in place, an access to /xmlui (no trailing slash) ends up with a slightly different response: HTTP/1.1 302 Moved Temporarily Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=78BBF6371FC69551818789FFC7806B6D; Path=/dspace-xmlui/; HttpOnly Location: http://localhost:8080/dspace-xmlui/ Content-Length: 0 Date: Tue, 27 Sep 2011 18:02:33 GMT The main difference between the two responses is that the XMLUI always responds with a 'Set-Cookie' which clears your old session cookie and replaces it with a new one. This is the underlying cause of the 'disappearing session' if you access the main XMLUI homepage without a trailing slash. If we can figure out a way to get the XMLUI/Cocoon to stop creating & setting a new Cookie, it should fix the issue completely (like in the JSPUI). But, at this point, I'm at a loss as to how to do that, since I'm not sure what is setting that Cookie. In the meantime, the above patch brings us about 95% of the way there. The user's login & session is kept in most every scenario. The only way the session is still "lost" is if the user manually changes the URL path in their browser to the XMLUI homepage without a trailing slash (e.g. http://localhost:8080/xmlui ). But, it is possible to even fix that scenario by changing your Tomcat 7 configuration to sessionCookiePathUsesTrailingSlash='false'.
        Hide
        tdonohue Tim Donohue added a comment -

        FIXED!

        I've figured out the issue with my previous patch.

        I've now attached a Version 2 patch (Tim-DS-959-Version2.patch), which seems to fix this issue in all major browsers. (The secret was to reset any existing response headers before doing a redirect, to ensure a new Cookie wasn't created.)

        So far, this patch seems to work for:
        DSpace 1.8.0 RC1/Trunk + Tomcat 7.0.21 (with default configs)
        on the latest versions of the following web browsers:
        Firefox, Chrome, Opera, IE, Safari (on Windows)

        It still may be useful to have someone else take a look at this small patch & try it out (just to make sure I'm not overlooking anything & that others approve of my implementation).

        I'll leave this open for comment for a day or two before committing to Trunk.

        Show
        tdonohue Tim Donohue added a comment - FIXED! I've figured out the issue with my previous patch. I've now attached a Version 2 patch (Tim- DS-959 -Version2.patch), which seems to fix this issue in all major browsers . (The secret was to reset any existing response headers before doing a redirect, to ensure a new Cookie wasn't created.) So far, this patch seems to work for: DSpace 1.8.0 RC1/Trunk + Tomcat 7.0.21 (with default configs) on the latest versions of the following web browsers: Firefox, Chrome, Opera, IE, Safari (on Windows) It still may be useful to have someone else take a look at this small patch & try it out (just to make sure I'm not overlooking anything & that others approve of my implementation). I'll leave this open for comment for a day or two before committing to Trunk.
        Hide
        tdonohue Tim Donohue added a comment - - edited

        I've added a Version3 of the patch which also fixes LDAP Authentication (at least I think it will – I don't have an LDAP Server to test with).

        Essentially, this ensures LDAPAuthenticationAction of XMLUI acts more like the ShibbolethAction. Previously the LDAPAuthenticationAction wasn't obeying the 'xmlui.user.loginredirect' setting. This fix also ensures a successful LDAP login will redirect to homepage with a trailing slash by default.

        If someone has an LDAP server handy (Stuart?), it'd be worth giving this a quick test to ensure this fix works for LDAP.

        Show
        tdonohue Tim Donohue added a comment - - edited I've added a Version3 of the patch which also fixes LDAP Authentication (at least I think it will – I don't have an LDAP Server to test with). Essentially, this ensures LDAPAuthenticationAction of XMLUI acts more like the ShibbolethAction. Previously the LDAPAuthenticationAction wasn't obeying the 'xmlui.user.loginredirect' setting. This fix also ensures a successful LDAP login will redirect to homepage with a trailing slash by default. If someone has an LDAP server handy (Stuart?), it'd be worth giving this a quick test to ensure this fix works for LDAP.
        Hide
        stuartlewis Stuart Lewis added a comment -

        Hi Tim,

        Details of my open test LDAP server (with copy and paste auth-ldap.cfg lines) can be found at http://blog.stuartlewis.com/tag/ldap/ There are two options, one for LDAPAuthentication and one for LDAPHierarchicalAuthentication.

        Thanks,

        Stuart

        Show
        stuartlewis Stuart Lewis added a comment - Hi Tim, Details of my open test LDAP server (with copy and paste auth-ldap.cfg lines) can be found at http://blog.stuartlewis.com/tag/ldap/ There are two options, one for LDAPAuthentication and one for LDAPHierarchicalAuthentication. Thanks, Stuart
        Hide
        tdonohue Tim Donohue added a comment -

        I've committed the Version 3 patch (see above) to Trunk (r6763), for release in 1.8.0.

        This patch was tested with both Tomcat 6 & Tomcat 7, and works in both without any special Tomcat configuration. It was also tested with LDAP authentication (using Stuart's test LDAP Server).

        Show
        tdonohue Tim Donohue added a comment - I've committed the Version 3 patch (see above) to Trunk (r6763), for release in 1.8.0. This patch was tested with both Tomcat 6 & Tomcat 7, and works in both without any special Tomcat configuration. It was also tested with LDAP authentication (using Stuart's test LDAP Server).

          People

          • Assignee:
            tdonohue Tim Donohue
            Reporter:
            stuartlewis Stuart Lewis
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: