[
https://jira.duraspace.org/browse/DS-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-959:
---------------------------
Attachment: Tim-DS-959.patch
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'.
> XMLUI login failure when using Tomcat 7.0.16
> --------------------------------------------
>
> Key: DS-959
> URL: https://jira.duraspace.org/browse/DS-959
> Project: DSpace
> Issue Type: Bug
> Components: XMLUI
> Affects Versions: 1.7.2
> Environment: Based on discussion on 'dspace-tech', seems to affect
> the following browsers:
> * IE
> * Chrome
> * Safari
> * Opera
> Reporter: Stuart Lewis
> Priority: Major
> Fix For: 1.8.0
>
> Attachments: Tim-DS-959.patch
>
>
> See: http://dspace.2283337.n4.nabble.com/Login-and-IE8-td3671944.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel