-
Type:
Service Pack Request
-
Status: Closed
-
Resolution: Fixed
-
Affects Version/s: 4.2.2
-
Fix Version/s: 4.2.5
-
Component/s: Repository Authentication and SSO, Share Application
-
Labels:None
-
Environment:any with kerberos and stripUsernameSuffix=false and IE8,9,11
-
Bug Priority:
-
ACT Numbers:
00313086
-
Build Location:
How to reproduce?
=================
1) create a 4.2.2 kerberos setup (linux pg tomcat) with ldap sync
This kerberos setup creates users that includes the domain name in the username, i.e:
alfresco-global.properties
kerberos.authentication.stripUsernameSuffix=false
and in share-config-custom.xml
<stripUserNameSuffix>false</stripUserNameSuffix>
Modify also the sync such that:
ldap.synchronization.userIdAttributeName=userPrincipalName
synchronization.autoCreatePeopleOnLogin=false
(see full JMX dump attached attached)
2) from a win7 client with IE8, as 'user1', go to your share server page
and confirm
a) you get SSO
b) you are redirected to:
http://madona:8080/share/page/user/user1%40example.foo/dashboard
3) now, hit in the web browser CTRL+T to create a new tab, and in that new tab, go to:
Results:
=======
That tab fails to access the dashboard.
It loops in an infinite 302 loop, see
302_loop.mp4 (video)
302_loop.pcap (network trace)
302_loop.txt (text network trace)
Expected result:
================
That new tab can also access the dashboard.
There is no infinite 302 loop.
Notes:
======
1) I reproduced this with IE8, customer reproduced it wit IE9 and IE11. Firefox is OK.
2) it is probably a case sensitivity issue.
Indeed, if we look just at the redirect, grepping the Location header:
# grep Location: 302_loop.txt | more Location: http://madona:8080/share/ Location: http://madona:8080/share/ Location: http://madona:8080/share/page/ Location: http://madona:8080/share/page/ Location: http://madona:8080/share/page/user/user1%40example.foo/dashboard Location: http://madona:8080/share/page/user/user1%40example.foo/dashboard Location: http://madona:8080/share/ Location: http://madona:8080/share/ Location: http://madona:8080/share/page/ Location: http://madona:8080/share/page/ Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard
(each url appears twice because of my setup), we see that the first redirect
Location: http://madona:8080/share/page/user/user1%40example.foo/dashboard
does not generate a loop, but that the second redirect does generate the loop:
Location: http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard
Note the different case of the realm part of the username.
3) one thing that is mysterious though, is that when using the 'curl' client, and asking for the upper case URL, I get a valid redirect to a lower case. I thus cannot reproduce the issue with curl, I do need IE:
# kinit user1 # curl -v --negotiate --user : --delegation always http://madona:8080/share/page/user/user1%40EXAMPLE.FOO/dashboard < HTTP/1.1 302 Found < Location: http://madona:8080/share/page/user/user1%40example.foo/dashboard .....
Now, let's follow the redirect:
# curl -v --negotiate --user : --delegation always http://madona:8080/share/page/user/user1%40example.foo/dashboard
< HTTP/1.1 200 OK
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Set-Cookie: JSESSIONID=9BD4FAFE3D7DED0EC3CFC96543103237; Path=/share/; HttpOnly
< Set-Cookie: Alfresco-CSRFToken=Jp6CIYxKwFqXxG7bmrn2PJt6%2fSeO5prucSD0bIfk6Pk%3d; Expires=Thu, 19-Mar-2015 14:36:37 GMT; Path=/share
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Cache-Control: no-cache
< Content-Type: text/html;charset=utf-8
< Content-Language: en-US
< Transfer-Encoding: chunked
< Date: Thu, 12 Mar 2015 14:36:37 GMT
<
{HTML Page code}
Conclusion: the loop cannot be reproduced using the command line.
Workaround:
==========
A workaround does exist: it is based on having a proxy in front of Share:
the proxy needs to intercept requests to:
http://madona:8080/share/page/user/user1%40EXAMPLE.FOO
and do the redirect itself to: