|
Hi all, has anyone run into problems with clients who go through a load-balancing proxy? I've had reports of people who can't log back in to DSpace after their session has timed out: " After clicking the Sign In button it sent me back to the home page not logged in. F5 and Ctrl-F5 had no effect." The problem occurs with IE and Firefox but not with Chrome. Clearing out the cookies resolves the problem (for Firefox at least). DSpace 1.8.2, XMLUI, Tomcat 6 behind Apache, XMLUI deployed at / Normal DSpace authentication, no other authentication methods enabled webui.session.invalidate and xmlui.user.loginredirect are both commented out in dspace.cfg as per default The DSpace log files show the user trying to authenticate, but the final request for the repository home page shows the user back as "anonymous", in line with the user's statement above. The session ID is the same though. Note this is a second attempt to authenticate, the first line even shows the user's e-mail address rather than anonymous (e-mail addresses, IPs and URLs changed in all log snippets): 2013-03-11 13:42:38,082 INFO org.dspace.authenticate.PasswordAuthentication @ u...@example.com:session_id=DB3A773E00B582FE826736A75211F0E3:ip_addr=client_ip:authenticate:attempting password auth of user=u...@example.com 2013-03-11 13:42:38,083 INFO org.dspace.authenticate.PasswordAuthentication @ u...@example.com:session_id=DB3A773E00B582FE826736A75211F0E3:ip_addr=client_ip:authenticate:type=PasswordAuthentication 2013-03-11 13:42:38,083 INFO org.dspace.app.xmlui.utils.AuthenticationUtil @ u...@example.com:session_id=DB3A773E00B582FE826736A75211F0E3:ip_addr=client_ip:login:type=explicit 2013-03-11 13:42:38,261 INFO org.dspace.app.xmlui.aspect.artifactbrowser.CommunityBrowser @ anonymous:session_id=DB3A773E00B582FE826736A75211F0E3:ip_addr=client_ip:view_community_list: The web server logs show that all requests that make up a login attempt from Chrome, and successful attempts from other browsers, come from the same source IP (different from the client IP in the DSpace log): proxy3 - - [11/Mar/2013:12:36:31 +1300] "GET /login HTTP/1.1" 302 - "http://{dspace.url}/" proxy3 - - [11/Mar/2013:12:36:38 +1300] "POST /password-login HTTP/1.1" 302 - "http://{dspace.url}/password-login" proxy3 - - [11/Mar/2013:12:36:38 +1300] "GET / HTTP/1.1" 200 32221 "http://{dspace.url}/password-login"With unsuccessful attempts from other browsers, the lines have different source IPs -- I assume this means the client goes through some sort of load-balancing proxy arrangement: proxy0 - - [11/Mar/2013:13:42:15 +1300] "GET /login HTTP/1.1" 302 - "http://{dspace.url}/" proxy2 - - [11/Mar/2013:13:42:19 +1300] "POST /password-login HTTP/1.1" 302 - "http://{dspace.url}/password-login" proxy1 - - [11/Mar/2013:13:42:19 +1300] "GET / HTTP/1.1" 200 28460 "http://{dspace.url}/password-login" Any ideas about what's going on and how to fix this? Or does this indicate some problem with the proxy configuration? cheers, Andrea -- Dr Andrea Schweer IRR Technical Specialist, ITS Information Systems The University of Waikato, Hamilton, New Zealand |
------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
