Cannot login with authremoteuser #2

jehanproc commented 2021年05月05日 22:49:57 +02:00

I use a SSO (shibboleth/SAML) served by a proxy Service Provider that set the HTTP variable HTTP_UID and not REMOTE_USER !

so I changed a bit your code by replacing every occurence of REMOTE_USER by HTTP_UID in auth.php, here's a diff from your distribution (+ add some print/debug prefix "debugjp" )

authremoteuse# diff auth.php auth.php.dist 
44d43
< 		 print "<p> is_writable($config_cascade debugjp: " . $config_cascade['plainauth.users']['default'];
51d49
< $this->cando['external'] = true;
75,78c73,75
< if (!empty($_SERVER['HTTP_UID'])) {
< 	$remoteUser = $this->cleanUser($_SERVER['HTTP_UID']);
< 		print "<p>debugjp: " . $remoteUser;
< 	$_SERVER['HTTP_UID'] = $remoteUser;
---
> if (!empty($_SERVER['REMOTE_USER'])) {
> 	$remoteUser = $this->cleanUser($_SERVER['REMOTE_USER']);
> 	$_SERVER['REMOTE_USER'] = $remoteUser;
85d81
< 		 print "<p>debugjp getUserData false: " . $userinfo;
92d87
< 		 print "<p>debugjp getUserData true: " . $USERINFO['name'] . $USERINFO['mail'] . $USERINFO['grps'];
438c433

After login (through my proxied SSO) , I do see the debug showing

is_writable(Array debugjp: /procacci/public/dok21/conf/users.auth.php

debugjp: jehan.procaccia_imtbs-tsp.eu

debugjp getUserData true: jehan.procacciaShibjehan.procaccia@imt-bs.euArray

So everything seemed correct, but I am not logged in , if I had the ?do=check at the end of the URL; doku.php?do=check , dokuwiki does says "You are currently not logged in" and the Log In link on the upper right is still there (not Log Out)

How can I further debug this pb ?
thanks .

PS: conf/users.auth.php does contain a line with appropiate value equal to HTTP_UID value .

I use a SSO (shibboleth/SAML) served by a proxy Service Provider that set the HTTP variable HTTP_UID and not REMOTE_USER ! so I changed a bit your code by replacing every occurence of REMOTE_USER by HTTP_UID in auth.php, here's a diff from your distribution (+ add some print/debug prefix "debugjp" ) ``` authremoteuse# diff auth.php auth.php.dist 44d43 < print "<p> is_writable($config_cascade debugjp: " . $config_cascade['plainauth.users']['default']; 51d49 < $this->cando['external'] = true; 75,78c73,75 < if (!empty($_SERVER['HTTP_UID'])) { < $remoteUser = $this->cleanUser($_SERVER['HTTP_UID']); < print "<p>debugjp: " . $remoteUser; < $_SERVER['HTTP_UID'] = $remoteUser; --- > if (!empty($_SERVER['REMOTE_USER'])) { > $remoteUser = $this->cleanUser($_SERVER['REMOTE_USER']); > $_SERVER['REMOTE_USER'] = $remoteUser; 85d81 < print "<p>debugjp getUserData false: " . $userinfo; 92d87 < print "<p>debugjp getUserData true: " . $USERINFO['name'] . $USERINFO['mail'] . $USERINFO['grps']; 438c433 ``` After login (through my proxied SSO) , I do see the debug showing is_writable(Array debugjp: /procacci/public/dok21/conf/users.auth.php debugjp: jehan.procaccia_imtbs-tsp.eu debugjp getUserData true: jehan.procacciaShibjehan.procaccia@imt-bs.euArray So everything seemed correct, but I am not logged in , if I had the ?do=check at the end of the URL; doku.php?do=check , dokuwiki does says "You are currently not logged in" and the Log In link on the upper right is still there (not Log Out) How can I further debug this pb ? thanks . PS: conf/users.auth.php does contain a line with appropiate value equal to HTTP_UID value .

Charly commented 2021年05月06日 23:37:26 +02:00

1. You should check whether HTTP_UID is seen by web server using phpinfo(): Search for HTTP_UID and for REMOTE_USER.
2. If it's seen: Did you follow all Usage steps?
3. It's important to remove all DokuWiki cookies from your browser (step 3).

HTH.

1. You should check whether `HTTP_UID` is seen by web server using `phpinfo()`: Search for `HTTP_UID` and for `REMOTE_USER`. 2. If it's seen: Did you follow all [Usage](https://www.dokuwiki.org/plugin:authremoteuser#usage) steps? 3. It's important to remove all DokuWiki cookies from your browser (step 3). HTH.

jehanproc commented 2021年05月07日 22:35:13 +02:00

1. yes I did checked with phpinfo() that HTTP_UID is set (no REMOTE_USER, as expected by the use of a shibboleth proxy Service Provider)
2. yes I followed Usage step and restarted from a newely freshly web browser (firefox vs chrome)

I realized in the "debug" print I added to auth.php :

< $remoteUser = $this->cleanUser($_SERVER['HTTP_UID']);
< print "

debugjp: " . $remoteUser;

it resulted in jehan.procaccia**_imtbs-tsp.eu and not jehan.procaccia@**imtbs-tsp.eu as seen in php_info
$_SERVER['HTTP_UID'] jehan.procaccia@imtbs-tsp.eu

so I added the jehan.procaccia**_**imtbs-tsp.eu login to users.auth.php , but still no success, still not logged In after SSO shibboleth proxied login and $_SERVER['HTTP_UID'] does contain jehan.procaccia@imtbs-tsp.eu

should I set _ or @ sign in users.auth.php login name ? (anyway I set both ...)
How can I further debug this issue ?

thanks .

1) yes I did checked with phpinfo() that HTTP_UID is set (no REMOTE_USER, as expected by the use of a shibboleth proxy Service Provider) 2) yes I followed Usage step and restarted from a newely freshly web browser (firefox vs chrome) I realized in the "debug" print I added to auth.php : < $remoteUser = $this->cleanUser($_SERVER['HTTP_UID']); < print "<p>debugjp: " . $remoteUser; it resulted in jehan.procaccia**_**imtbs-tsp.eu and not jehan.procaccia**@**imtbs-tsp.eu as seen in php_info $_SERVER['HTTP_UID'] jehan.procaccia@imtbs-tsp.eu so I added the jehan.procaccia**_**imtbs-tsp.eu login to users.auth.php , but still no success, still not logged In after SSO shibboleth proxied login and $_SERVER['HTTP_UID'] does contain jehan.procaccia@imtbs-tsp.eu should I set _ or @ sign in users.auth.php login name ? (anyway I set both ...) How can I further debug this issue ? thanks .

Charly commented 2021年05月08日 18:33:35 +02:00

In this case, I assume the problem is that the ID in HTTP_UID doesn't match the user's ID in conf/users.auth.php because of the cleaning functionality of DokuWiki:

1. Compare the ID in conf/users.auth.php to your debug output.

2. Try this, please:

   if (!empty($_SERVER['HTTP_UID'])) {
    $remoteUser = $this->cleanUser($_SERVER['HTTP_UID']);
    $_SERVER['REMOTE_USER'] = $remoteUser;
    var_dump($remoteUser);
   

HTH.

In this case, I assume the problem is that the ID in `HTTP_UID` doesn't match the user's ID in `conf/users.auth.php` because of the cleaning functionality of DokuWiki: 1. Compare the ID in `conf/users.auth.php` to your debug output. 2. Try this, please: ```php if (!empty($_SERVER['HTTP_UID'])) { $remoteUser = $this->cleanUser($_SERVER['HTTP_UID']); $_SERVER['REMOTE_USER'] = $remoteUser; var_dump($remoteUser); ``` HTH.

Charly commented 2021年05月15日 16:03:24 +02:00

Since there was no more feedback after five working days, this issue has been closed.

Since there was no more feedback after five working days, this issue has been closed.

jehanproc commented 2021年05月17日 10:03:43 +02:00

Sorry, I didn't saw your answer .

your correction works fine :

$_SERVER['REMOTE_USER'] = $remoteUser;
 var_dump($remoteUser);

I guess my mistake was that I replaced REMOTE_USER with HTTP_UID in every occurence of REMOTE_USER, and it wasn't appropriate in that last one :

 $_SERVER['REMOTE_USER'] = $remoteUser;

does the vardump($remoteUser); needs to be kept ? or was it just a debug/test ?

more Generally in terms of security, what if someone adds a forge HTTP_UID (or REMOTE_USER) variable in the request to dokuwiki login page,will he be "blindly" logged in by authRemoteUser plugin ?

thanks .

Sorry, I didn't saw your answer . your correction works fine : ``` $_SERVER['REMOTE_USER'] = $remoteUser; var_dump($remoteUser); ``` I guess my mistake was that I replaced REMOTE_USER with HTTP_UID in every occurence of REMOTE_USER, and it wasn't appropriate in that last one : > $_SERVER['REMOTE_USER'] = $remoteUser; does the *vardump($remoteUser);* needs to be kept ? or was it just a debug/test ? more Generally in terms of security, what if someone adds a forge HTTP_UID (or REMOTE_USER) variable in the request to dokuwiki login page,will he be "blindly" logged in by authRemoteUser plugin ? thanks .

Charly commented 2021年05月17日 11:13:46 +02:00

1. var_dump($remoteUser); was added for your debugging.
2. REMOTE_USER could be faked by an attacker!

1. `var_dump($remoteUser);` was added for your debugging. 2. `REMOTE_USER` could be faked by an attacker!