[xwiki-users] User Session not sticky behind IIS8 Reverse Proxy
Hi everyone, I'm having trouble setting up Xwiki behind my Reverse Proxy. As a reverse proxy I have to use IIS. With ARR and URL Rewrite. The rewrite rules are on the default web site and rwrite to http://localhost:port/xwiki (this will later be changed to https) Now if I log into my Xwki with a user or an admin, if I click on any link the account isn't logged in anymore. I don't have this problem with several other applications (for instance YouTrack or Nexus), nor does it occur if I bypass the proxy. Any ideas would be welcomed. Have a nice day, Jack -- View this message in context: http://xwiki.475771.n2.nabble.com/User-Session-not-sticky-behind-IIS8-Revers... Sent from the XWiki- Users mailing list archive at Nabble.com.
Hi Jack,
Hi everyone,
I'm having trouble setting up Xwiki behind my Reverse Proxy.
As a reverse proxy I have to use IIS. With ARR and URL Rewrite. The rewrite rules are on the default web site and rwrite to http://localhost:port/xwiki (this will later be changed to https)
Now if I log into my Xwki with a user or an admin, if I click on any link the account isn't logged in anymore.
I don't have this problem with several other applications (for instance YouTrack or Nexus), nor does it occur if I bypass the proxy.
Any ideas would be welcomed.
Is XWiki running as a cluster, so the session needs to be sticky? One problem I can think of is that the session cookie keeping the login is set for the wrong domain. You can check in the browsers "developer tools" for a "Set-Cookie" header coming in from the server. The alternative is the XWiki-cluster experiences your user's requests coming in from different IPs. Set the "xwiki.authentication.validationKey" and "xwiki.authentication.encryptionKey" in xwiki.cfg. If you keep them at their (commented) defaults, XWiki uses an autogenerated key which uses the client-IP and this causes the user to get logged out if the client IP changes. hope this helps Clemens
Have a nice day, Jack
-- View this message in context: http://xwiki.475771.n2.nabble.com/User-Session-not-sticky-behind-IIS8-Revers... Sent from the XWiki- Users mailing list archive at Nabble.com. _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Every Application is running on it's own Tomcat. With Google Chromes Developer Tool I can see that the cookie drops Username, Password, Validation and rememberme when I click a link. I just want the user to stay logged in as long as he wants. I do have the sneaky suspicion that the latter option you provide hits the nail on the head: When using Wireshark to trace the problem, I can clearly see the handshake happening with Nexus from one IP to another. With Xwiki I can't find an equivalent, it doesn't even show IPs anymore, but lots of gibberish I don't understand and Broadcasts. Normally all Clients use fixed IPs on our network, so I don't know why this would happen. I will try to set the keys. Thank you for your input, Jack -- View this message in context: http://xwiki.475771.n2.nabble.com/User-Session-not-sticky-behind-IIS8-Revers... Sent from the XWiki- Users mailing list archive at Nabble.com.
Ok, I just checked the xwiki.cfg
#--------------------------------------- # Authentication and authorization #
#-# Enable to allow superadmin. It is disabled by default as this could be a #-# security breach if it were set and you forgot about it. Should only be enabled #-# for recovering the Wiki when the rights are completely messed. xwiki.superadminpassword=system
#-# Authentication type. You can use 'basic' to always use basic authentication. # xwiki.authentication=form
#-# Indicate if the authentication has do be done for each request #-# 0: the default value, authentication is done only once by session. #-# 1: the authentication is done for each request. # xwiki.authentication.always=0
#-# Cookie encryption keys. You SHOULD replace these values with any random string, #-# as long as the length is the same. xwiki.authentication.validationKey=totototototototototototototototo xwiki.authentication.encryptionKey=titititititititititititititititi
#-# Comma separated list of domains for which authentication cookies are set. This #-# concerns mostly wiki farms. The exact meaning is that when a user logs in, if #-# the current domain name corresponding to the wiki ends with one of the entries #-# in this parameter, then the cookie is set for the larger domain. Otherwise, it #-# is set for the exact domain name of the wiki. #-# #-# For example, suppose the cookiedomains is set to "mydomain.net". If I log in #-# on wiki1.xwiki.com, then the cookie will be set for the entire mydomain.net #-# domain, and if I visit wiki2.xwiki.com I will still be authenticated. If I log #-# in on wiki1.otherdomain.net, then I will only be authenticated on #-# wiki1.otherdomain.net, and not on wiki2.otherdomain.net. #-# #-# So you need this parameter set only for global authentication in a #-# farm, there's no need to specify your domain name otherwise. #-# #-# Example: xwiki.authentication.cookiedomains=xwiki.org,myxwiki.org xwiki.authentication.cookiedomains=
If I read this correctly the keys aren't at their default, because they aren't commented out? I haven't touched the .cfg up to now. -- View this message in context: http://xwiki.475771.n2.nabble.com/User-Session-not-sticky-behind-IIS8-Revers... Sent from the XWiki- Users mailing list archive at Nabble.com.
On 02/05/2014 02:52 PM, Deichgraf wrote:
Ok, I just checked the xwiki.cfg
[...]
If I read this correctly the keys aren't at their default, because they aren't commented out? I haven't touched the .cfg up to now.
The default is "unset" (I think). Anyway, you are expected to uncomment them and replace the dummy text by some random non-dummy text. Something I forgot: To test the "request coming in from different IP's" hypothesis You also need to set: xwiki.authentication.useip=false (which is not present in the xwiki.cfg) See: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Security#HCookies Clemens
Thank you useip=false was the solution. We got everything to work the way we wanted. Sadly our boss took the project away from us, after our .NET framework caused problems out of the blue. -- View this message in context: http://xwiki.475771.n2.nabble.com/User-Session-not-sticky-behind-IIS8-Revers... Sent from the XWiki- Users mailing list archive at Nabble.com.
participants (2)
-
Clemens Klein-Robbenhaar -
Deichgraf