Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-17171

XWiki Continuously Re-Authenticates While HTTP Authorization Headers are Present


    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 11.10.3
    • Fix Version/s: None
    • Component/s: Old Core
    • Labels:
    • Difficulty:
    • Similar issues:


      Thomas Mortagne: FYI, the requested issue report. Not sure if it's actually a "Bug" or rather a feature request.

      In my setup, I'm using an Apache httpd reverse proxy in front of the locally listening Tomcat 9 in which Xwiki is running.

      I manage my users using LDAP, and the Apache httpd already authenticates the users via HTTP Basic Authentication before forwarding the request to Tomcat / Xwiki.

      Rather by random chance Thomas Mortagne had a glimpse at my logs and noticed that Xwiki was continuously re-authenticating the user session using LDAP, even for REST requests during page loads.

      Xwiki always feels somewhat sluggish on my system, and permanently performing LDAP lookups on every request probably does not really help here...

      As far as I could see, there was no warning whatsoever in the logs that something was "messed up" with the authentication configuration, leading to such a misbehaviour.

      At least a big, fat, easy to find warning would be good here, or maybe just to rely on the user name after the session setup instead of reauthenticating all the time. (As in "Trusted Authentication" mode, if this does not create security holes.)

      My reverse proxy setup was as follows:

      <VirtualHost *:443>
              ServerName xwiki.example.com
              ServerAdmin webmaster@example.com
              DocumentRoot /var/www/html
              ErrorLog ${APACHE_LOG_DIR}/xwiki.example.com_error.log
              CustomLog ${APACHE_LOG_DIR}/xwiki.example.com_access.log combined
              SetEnvIf Request_URI "/.well-known/acme-challenge/" is_accessible_target
              #SetEnvIf Request_URI "/xwiki-websocket/" is_accessible_target
              <Location "/">
                      #SetHandler ldap-status
                      #Require host yourdomain.example.com
                     AuthType Basic
                     AuthName "LDAP Protected"
                     AuthBasicProvider ldap
                     AuthLDAPURL "ldaps://,dc=example,dc=com?uid?one"
                     AuthLDAPBindDN "cn=abc,dc=example,dc=com"
                     AuthLDAPBindPassword "secr3t"
                             Require valid-user
                             Require env is_accessible_target
              Include /etc/apache2/local_harden_ssl.conf
              SSLCertificateFile /var/lib/dehydrated/certs/collab.example.com/fullchain.pem
              SSLCertificateKeyFile /var/lib/dehydrated/certs/collab.example.com/privkey.pem
              ## Can you use Redirect and Proxypass at the same time
              ## https://serverfault.com/questions/605931
              ## Use “Redirect” and “ProxyPass”
              ## https://stackoverflow.com/questions/26595592
              RedirectMatch permanent ^/$ /xwiki/
              ## RedirectMatch seeother ^/xwiki/?$ /xwiki/bin/view/Startseite/ ## Tut nicht, siehe oben
              ProxyPass "/xwiki/" "ajp://localhost:8009/xwiki/"
              ## ProxyPassReverse "/xwiki/" "ajp://localhost:8009/xwiki/"
              ## Workaround fuer JavaScript-Problem in XWiki Diagram-App
              Header unset X-Content-Type-Options
              Header set X-Frame-Options "allow-from https://nextcloud.example.com/"

      I'm now trying to work around this issue by enabling xwiki.authentication.ldap.httpHeader=REMOTE_USER in xwiki.cfg and adding

              RequestHeader unset Authorization
              RequestHeader set REMOTE_USER expr=%{REMOTE_USER}

      to my reverse proxy config.

      Still waiting for confirmation from Thomas Mortagne that this actually helped.

      "Placebo estimation" suggests that afterwards Xwiki feels somewhat more responsive already...




            • Assignee:
              GOhrner Gunter Ohrner
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created:
                Date of First Response: