DSpace
  1. DSpace
  2. DS-959

XMLUI login failure when using Tomcat 7.0.16

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Major 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
    1. Tim-DS-959.patch
      6 kB
      Tim Donohue
    2. Tim-DS-959-Version2.patch
      6 kB
      Tim Donohue
    3. Tim-DS-959-Version3.patch
      7 kB
      Tim Donohue

      Activity

      Hide
      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'.
      Show
      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
      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
      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
      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
      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
      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
      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
      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
      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:
          Tim Donohue
          Reporter:
          Stuart Lewis
        • Votes:
          0 Vote for this issue
          Watchers:
          1 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved: