Extension talk:Auth remoteuser/Archive

If you have errors, please check m:User talk:Otheus/Auto Login via REMOTE USER for potential solution.

Extension has been refactored
Note that any code snippets below are now irrelevant as the extension code has been refactored. All the logic has been moved to a new class file. Formina Sage (talk) 20:16, 17 June 2015 (UTC)

Login Error was:EmptyPass
i think this could possibly be a symptom of a security issue.

just did a big update of the wikis i run for my company up to 1.19.1 and decided to use this extension for sso authentication. it works great, thanks! i am having one issue however that i'm not certain where it's coming from / the ramifications of it.

i had to do some finagling of the initUser section to get usernames, real names, and email address to populate correctly:

if ( isset( $wgAuthRemoteuserName ) ) { $user->setRealName( $wgAuthRemoteuserName ); } else { // lower username to make $emailname $emailname = strtolower( $username ); // remove. from emailname and replace with space to make $realname $realname = str_replace( ".", " ", $emailname ); // uppercase first letter of each word to make scott happy $realname = ucwords( $realname ); $user->setRealName( $realname ); }               if ( isset( $wgAuthRemoteuserMail ) ) { $user->setEmail( $wgAuthRemoteuserMail ); } elseif ( isset( $wgAuthRemoteuserMailDomain ) ) { $user->setEmail( $emailname . '@' . $wgAuthRemoteuserMailDomain ); } else { $user->setEmail( $username . "@example.com" ); }

after our cut over to production, there were a number of users that got a new user account instead of hitting their old one. it took me a little bit of time, but i realized that the REMOTE_USER variable being passed was sometimes all UPPERCASE and sometimes all lowercase depending on the user. i fixed it by adding a line to the username processing section:

if ( isset( $wgAuthRemoteuserDomain ) && strlen( $wgAuthRemoteuserDomain ) ) { // lower remote_user for consistency $username = strtolower( $_SERVER['REMOTE_USER'] ); $username = str_replace( "$wgAuthRemoteuserDomain\\", "", $username ); $username = str_replace( "@$wgAuthRemoteuserDomain", "", $username ); } else { $username = strtolower( $_SERVER['REMOTE_USER'] ); }

in production the extension seems to be functioning properly now. the problem is i've now backed up [via mysqldump] and synced [via rsync] over to my development system. with this code when i try and log on i'm allowed access as anonymous! in the error log, i'm seeing:

Unexpected REMOTE_USER authentication failure. Login Error was:EmptyPass

i think the key to all of this may be that my REMOTE_USER is inconsistent between the production sso and the dev sso. e.g. on prod i'm FIRSTNAME.LASTNAME@MYDOMAIN.COM and on dev i'm firstname.lastname@mydomain.com.

when i remove the changes to the username processing section it works properly provided the REMOTE_USER returned and $wgAuthRemoteuserDomain are the same case.

i've tried to provide as much detail as possible, but if there is something else you need to know, please don't hesitate to contact me. i'm running about 70 wikis in production, and having this code be inconsistent between dev and prod is stressing me out a bit.

-Zeefreak (talk) 14:38, 27 June 2012 (UTC)

Random blank page
This extension works perfectly with the 1.15.1 version. However, I have randomly a blank page when accessing the wiki. It happens only when this particular extension is enabled. Does anyone know how to fix that? Thanks!


 * I'm getting a similar error. SOME users get a 500 HTTP code with a blank page. It doesn't even display the error in the content, it's just the header. But this isn't for ALL users. The users who fail always fail, and the users who work always work. The error happens regardless of the browser or client being used, so it is tied to the specific users. There are no special characters or other oddities in the usernames, either (Some username capitalizations are different between what's reported as the Remote_User in phpinfo, but others aren't). No errors are logged in the PHP error log or in the wiki log when debugging is on. When I turn the extension off, no errors occur.
 * As with the previous comment, this was working fine on 1.15.1, but not on 1.18.1. I even made a 100% fresh 1.18.1 install to test with, and the same users get the same errors. I'm running the following: MediaWiki 1.18.1; PHP 5.3.10 (cgi-fcgi); MySQL 5.5.17; running IIS on a Windows XP machine --DarthZeth (talk) 17:45, 22 March 2012 (UTC)
 * Well now I feel dumb. Someone pointed out that the working users had admin access to the box. Turns out my wikiusers group didn't have read/execute permissions for the extension file for whatever reason, which was causing the error. So wrong permissions might be the cause of other 500 error/blank page problems. --DarthZeth (talk) 19:12, 22 March 2012 (UTC)
 * Well now I feel dumb. Someone pointed out that the working users had admin access to the box. Turns out my wikiusers group didn't have read/execute permissions for the extension file for whatever reason, which was causing the error. So wrong permissions might be the cause of other 500 error/blank page problems. --DarthZeth (talk) 19:12, 22 March 2012 (UTC)

$_SERVER['REDIRECT_REMOTE_USER']
Seemed to work under 1.12pre, once I added near the top of Auth_remoteuser.php: if (!isset($_SERVER['REMOTE_USER'])) $_SERVER['REMOTE_USER'] = $_SERVER['REDIRECT_REMOTE_USER']; Jlerner 00:55, 11 December 2007 (UTC)

How does the extension know who to login?
I like this program and think it could be used very well with my website. We have a PHPBB forum and a localized login script for that on our site. What I would like is for users who login using the localized form to automatically be logged into PHPBB AND the wiki. However I am confused as to where the users login info fits into all of this? Any help will be appreciated. Thanks :P

Auto login locally?
Hi, I want to implement a Wiki internally at the company I work for and an auto-login function would be very welcome. We're using WinXP machines on DNS and would like a way to automatically pass across winodws credentials of users retrieving any details needed from AD. Is this possible and if so how would I go about doing it? Bear in mind that it is not public facing so convenience can come before security here.


 * You're looking for "Single Signon" functionality. If your web server can provide this - then this extension will use the authentication info from the server to log you into the wiki. This extension would be part of your solution... but there may be other options available.


 * Although i am using my own extension, this might be helpful. I am using LDAP to fill in the Real Name and Mail fields. Still if i want users to authenticate against NTLM (SSPI) i either have to save their password as their wiki password, to fill the user prefs or i need to have a dummy query user for calling LDAP. I am still not sure which solution is better. Passwords may change and a global user is a potential security risk.


 * This extension can be used in conjuction with Windows Authentication on IIS to allow a user access the wiki from IE on a domain local machine to be automatically authenticated with the wiki. VibroAxe 10:33, 10 December 2009 (UTC)

Apache, Windows and mod_auth_sspi
If you are using this extension with Apache on Windows, and are using mod_auth_sspi to populate REMOTE_USER, make sure that you use 1.0.3 of the module and not 1.0.4. The later version strips POSTed information. I confirme : With the 1.0.4 version of the mod_auth_sspi module i had a blanck page when i made a preview. With the 1.0.3 version, all is OK.

Cached Pages showing wrong user name
I had to turn off the server side cache to make this work properly with 1.9.3. Otherwise the user name shown at the top of the screen would sometimes be correct, and sometimes show the previous user's name, if the previous user had accessed the given page. This doesn't happen with normal user logout/login, so I assume it is to do with the AutomaticREMOTE_USER logout/login cycle. When I try to edit a page showing the wrong user name, (and the previous user hasn't tried to edit it also), the the correct user name shows on the edit page. Disabling the cache probably isn't the best solution. Any clues?

login problems with wrong REMOTE_USER
The plugin doesnt work on our system (IIS 6, Win2k3 AD, MW 1.13.2). It changed REMOTE_USER from foo_bar\username to foo bar\username. After removing foo_bar\ from username by substr($_SERVER['REMOTE_USER'],10) it works fine for us.

SunAM Authentication and authorization
I'm using the extension with Mediawiki 1.15.1 and Apache 2.2.11 with SunAM authentication.

Problems with name normalization and patch
For Mediawiki 0.13 (and above, I presume), I found I needed to do the following to allow users with underscores in their name to login:

--- remoteuser.php.orig       2009-09-14 11:41:25.000000000 -0400 +++ remoteuser.php 2009-09-14 11:39:21.000000000 -0400 @@ -229,7 +229,8 @@       return false; return isset($_SERVER['REMOTE_USER']) && -          (strtolower($username) == strtolower($_SERVER['REMOTE_USER'])); +          (strtolower($username) == +            strtolower(User::getCanonicalName($_SERVER['REMOTE_USER']))); }  /**

How about newer version?
I have the same issue with "allowing users with underscores in their name to login" but using a newer version of mediawiki (1.17.4) as well as a newer version of Auth_remoteuser.php which is nothing like the code listed above! Thoughts?

Patch above, rewritten for 1.19.1
This fixed my issue, after I ported it for MediaWiki 1.19: --- Auth_remoteuser.php.orig	2012-06-26 19:32:00.000000000 -0500 +++ Auth_remoteuser.php	2012-09-18 17:39:07.089290200 -0500 @@ -297,7 +297,7 @@ 			$usertest = $_SERVER['REMOTE_USER']; } -		return ( strtolower( $username ) == strtolower( $usertest ) ); +		return ( strtolower( $username ) == strtolower( User::getCanonicalName( $usertest ) )); } 	/**

That's it - Works great, thanks!!

Implementation?
How exactly is this extension used? Are there examples?

Gotcha: WikiSysop login
If you created a WikiSysop account during Mediawiki installation, you won't be able to use that account unless it authenticates with whatever mechanism you're using to set REMOTE_USER. Keep that in mind.
 * Second that. Have to turn off extension for access to the old account. --Kebap (talk) 23:40, 15 December 2013 (UTC)

OK with LDAP for me
Just because the notice on the main page is so scary... I got this going under Apache 2.2 on CentOS with the mod_authnz_ldap extension with no particular problems. The only note would be that I didn't need to worry about REMOTE_USER in my case, it was all set up already.

Active Directory SSO
Has anyone managed to get this extension working with an Active Directory SSO configuration? Specifically, retrieving HTTP headers, and automatically creating users.

I've tried setting allowPasswordChange and setPassword to true, but auto account creation doesn't seem to work.

--Enterprise user 21:15, 20 December 2010 (UTC)


 * Never mind, resolved the problem.


 * I just replaced the phrase 'REMOTE_USER' in Auth_remoteuser.php with 'HTTP_USERNAME'. User account is automatically generated now.


 * --Enterprise user 22:02, 20 December 2010 (UTC)


 * I changed the line $username = ""; to $username = getenv("username");

E-mail address as User Name
Does anyone know if using an e-mail address as a MediaWiki username is problematic? The e-mail address follows the following convention:

first.lastname@domain.com

--Enterprise user 22:04, 20 December 2010 (UTC)

The code that runs to test "if a user_name" is valid disallows '@', '/' and '#'. Based on user.php class in MediaWiki 1.15. Mike Papper

Active Directory integration with Apache & Groups support
I've made some modifications to this extension that along with a bit of configuration on the Apache server allow AD users to login with full group information copied over to the auto-created MediaWiki account. Setup instructions are in the header comments of the file below. (Sorry for the full paste instead of a diff, but I haven't had any luck applying diff's to copy/paste code from wiki pages.)

Wiki Admin
When enabling this extension, the Wiki Admin account, which exists out of my LDAP authentication environment, cannont be accessed due to the absence of a login form. Is there a method by which I can access this account while the extension is active? --Enterprise user 19:51, 24 January 2011 (UTC)
 * Facing the same problem, I enabled the extension, had my account auto-created, and then disabled it. Then I logged in as sysop, granted my newly-created acount Beurocreat and sysop permissions, and re-enabled the extension. Would this work for you as well? Ethan1701 17:11, 30 January 2011 (UTC)
 * Don't see why that wouldn't work; thanks! The only issue I see with this solution is that modifications made by me to the Wiki won't appear with the username Admin; I suppose I could live with that. --Enterprise user 17:38, 31 January 2011 (UTC)

Full name (AUTHENTICATE_CN) not getting populated
I installed this extension without a hitch. Works well. However, it's not populating the Real Name field for the user. The segment of code that's meant to do it, as best I can tell, is Though I can confirm that $_SERVER["AUTHENTICATE_CN"] does in fact have a value, it's not being passed through. Might the fact it's in Hebrew affect things?

Is there any way I can remove the user in order to modify and test the code? Ethan1701 17:17, 30 January 2011 (UTC)


 * How do you find out if the $_SERVER["AUTHENTICATE_CN"] variable is being populated? it's not in my phpinfo. I'm using iis7 as my web server, is there any way to configure it to populate the variable


 * Thanks for any help - Boozelclark 07:00, 20 May 2011 (UTC)

Problem with the Extension
When enabling this extension I get the following ErrorMessage:

Fatal error: Cannot make non static method AuthPlugin::getCanonicalName static in class Auth_remoteuser in /var/www/wiki/extensions/Auth_remoteuser/Auth_remoteuser.php on line 202

What can I Do to make it work?--Bayano 14:48, 23 March 2011 (UTC)

Require Once issue
The LocalSettings.php require line is out of date and should be updated to this

--16:48, 6 April 2011 (UTC)

Unable to modify username
This extension worked beautifully right out of the box. Thank you. I'm now trying to modify the automatically generated usernames. Right now, usernames are defaulting to name@domain.com. (I've noticed that the extension tries to strip out the @domain.com, but it's not working.) Having the domain in there creates a few problems, so I'm trying to truncate the username to "name". I've tried:

$username = strstr( $username, '@', true);

in both the Auth_remote_user_hook and initUser functions, but it did nothing. If I log out and visit another page, it logs me back in as name@domain. Any suggestions? MatthewBurton 21:48, 1 July 2011 (UTC)


 * Fixed. I hadn't changed my $wgAuthRemoteuserDomain value from NETBIOSDOMAIN (line 80). Once I replaced that with my own domain, everything worked perfectly. MatthewBurton 21:29, 6 July 2011 (UTC)

Solved: $wgAuthRemoteuserName and $wgAuthRemoteuserMail inappropriately set:
Line 71 sets the variable during a ternary check even if $_SERVER["AUTHENTICATE_CN] is NOT set: $wgAuthRemoteuserName = isset( $_SERVER["AUTHENTICATE_CN"] ) ? $_SERVER["AUTHENTICATE_CN"] : '' ; The ternary check should set $wgAuthRemoteuserName to 'null' when $_SERVER["AUTHENTICATE_CN] is not set: $wgAuthRemoteuserName = isset( $_SERVER["AUTHENTICATE_CN"] ) ? $_SERVER["AUTHENTICATE_CN"] : null; Otherwise, the later check in initUser line 374 succeeds where it should fail: if ( isset( $wgAuthRemoteuserName ) ) { $user->setRealName( $wgAuthRemoteuserName ); } else { $user->setRealName( '' ); } This is also true of $wgAuthRemoteuserMail check. --Secmanz 02:43, 8 October 2011 (UTC)

Error messages as of MediaWiki 1.18
Date: 8 january 2012 The following errors turn up in the Apache log file after installing MediaWiki 1.18.0 although everything works fine:

PHP Strict Standards: Declaration of Auth_remoteuser::modifyUITemplate should be compatible with that of AuthPlugin::modifyUITemplate in /volume1/web/w/extensions/Auth_remoteuser/Auth_remoteuser.php on line 202, referer: https://MyServer/MyWikiPage PHP Strict Standards: Declaration of Auth_remoteuser::addUser should be compatible with that of AuthPlugin::addUser in /volume1/web/w/extensions/Auth_remoteuser/Auth_remoteuser.php on line 202, referer: https://MyServer/MyWikiPage PHP Strict Standards: Declaration of Auth_remoteuser::initUser should be compatible with that of AuthPlugin::initUser in /volume1/web/w/extensions/Auth_remoteuser/Auth_remoteuser.php on line 202, referer: https://MyServer/MyWikiPage

I use the following versions: MediaWiki 1.18.0 (r108167) PHP       5.3.3 (apache2handler) MySQL     5.1.49 AutomaticREMOTE USER 1.1.4 (r108355)


 * Has this bug been fixed? As far as I can tell it has only been reported on the code review site. Thank you for any updates anyone can provide! --MediaWikiFan (talk) 19:34, 30 November 2012 (UTC)

Multiple Domain Authentication
Our corporation uses multiple domains.

It seems it would make sense if the $wgAuthRemoteuserDomain was an array. $wgAuthRemoteuserDomain = array( "DOMAIN1", "DOMAIN2", "DOMAIN3" );

Anyone else have a need for more support?

Case Insensitive Domains
Our wiki lets users login with either NTLM or a typed username/password from the 403 challenge. This has the effect that users type the domain differently, often lowercased, which allows them to login, but results in duplicate user names.

Has anyone else seen this / would like this fixed?

I'm guessing it's due to using  rather than   to remove the domain part of the name, but I'm not sure what (if any) other side-effects this might have? Perhaps this should be made optional in case users have case sensitive domains?

phpBB
How to make this extension work with phpbb (phpbb uses a database to store data about the authorization)? --89.179.33.86 17:14, 16 July 2012 (UTC)

Only allow certain users to view
I'm running this extension successfully on my organization's intranet. However, my management has decided they don't want to let all of the 1000's of people on our intranet to be able to view the wiki. We'd like to keep it limited to the 200 or so actual users.

When a person first navigates to a wiki using this extension, it automatically creates their username and adds them to the group "user". My initial thought was to remove "view" privileges from the group "user". This did not work. I assume it is built into MediaWiki that anyone with a username is able to view pages.

So I added people who should be allowed to view the wiki to the "Viewers" group, then added the following code to the Auth_remoteuser::authenticate method:

Can anyone help me improve upon this?

Also, note that I commented out a section of the auth_remote_user_hook function, which is probably not ideal long term. The code below (which I commented out on my server) caused me to be already logged in via session data, thus I was getting around the Auth_remoteuser::authenticate method. After commenting it out I was forced into the authenticate method on each page load.

Thanks in advance!

--Jamesmontalvo3 (talk) 17:25, 8 January 2013 (UTC)

Solved my own problem
I made an addition to Auth_remoteuser.php to allow me to:
 * 1) Only allow users of a certain group to view the wiki (it seems simply removing the view right from "users" does not work)
 * 2) * Block most users despite being valid $_SERVER["REMOTE_USER"]
 * 3) Allow these non-viewers to view one page, in my case Project:Access_Denied
 * 4) Also allow them to view Project_Talk:Access_Denied
 * 5) * With Extension:Talkright, this allows these non-viewers to edit the talk page, where they can request access (Admins are all watching this page)
 * 6) * Giving them the talk right is a security risk, since they can then transclude other pages into this page...but that's not a big deal in my case

I did this by adding the following code to Auth_remoteuser.php:

Add the code above to the Auth_remote_user_hook function, just below this block of code:

The $wgAuthRemoteuserViewerGroup, $wgAuthRemoteuserDeniedPage and $wgAuthRemoteuserDeniedNS settings could probably be moved to LocalSettings.php, or at least to the top of Auth_remoteuser.php, but I haven't tested that out yet.

--Jamesmontalvo3 (talk) 00:03, 19 January 2013 (UTC)

Update Database when Email or Username changes for the same user_name
I am using a cookie to set REMOTE_USER. In the cookie is the user_name, email and fullname. If this is the very first time the site has seen that user_name, they will be added to the DB with the given email and fullname. but if they already exist (the same user_name) the email and fullname are not updated.

I want to add a check for this and update as needed - and it should occur only when the session is being re-created (so we dont need to check the DB for each and every request). Im looking in code to do this - if anyone has any pointers or advice it would be appreciated.

Mike

Username with underline
Can't login :(

Alex

Conditional login
I am trying to set up MediaWiki so users from a remote network must log in, but it's optional on the local network. I don't want users to have to log in twice, so I set up this extension, which works well for remote users. I've tried a variety of hacks, including setting a directory where the local user must log in then directing them back, but Apache won't pass REMOTE_USER in the MW directory for a local user, and other hacks are all ugly in one way or another. Does anyone have any ideas? Thanks! BTW I'm using ldap.

user changing their own preferences triggers password request
So I've set this up in a wiki that is itself in an url space that is accessible only to folks registered with our LDAP server. So far all is good, although remote users wind up with a capitalized version of their username o.O... Anyway, this means that users on the wiki have already authenticated well before even entering the wiki.

But if a user wants to change their preferences, there are instances (such as changing email address) that suddenly requests a password. Is there a way to handle this so as not to do this? I don't see why the wiki should know about the password; I don't think this is even set up to properly authenticate again with the original LDAP, so this seems a potential insecurity for folks' passwords here.

recommended method for editing initUser?
So the instructions only briefly say

"initUser -- configure this routine according to your particular environment to update the email address and other information in the MediaWiki database to match the authentication source."

Does this mean to edit the Auth_remoteuser.php file directly? Or is there a recommended practice, such as an include file, or a hook? Seems like I'd risk having my mods stomped on each time I updated this extension. Since my setup doesn't properly configure AUTHENTICATE_CN or AUTHENTICATE_MAIL, I thought I'd set up a quick ldap connection to do so, but it's not clear if I should do this within initUser, or just dump the code in LocalSettings.php.

(New to mediawiki, but an old hand at other things like Wordpress, from which I've inherited a nice amount of paranoia :-P )

Unable to login. Please help!
Hello,

I have implemented this extension and has configured to the IIS settings as mentioned in the page.

When I enabled windows authetication in IIS, it shows me the prompt on IE/Chrome/Firefox and when I entered DOMAINNAME\USERNAME and password, it denies my entry. It keeps looping.

However, when I enabled basic auth instead of windows auth, it prompts me again but when I entered DOMAINNAME\Username and password, I am able to login.

Why is that so?

Please help.

Thanks so much for all the assistance!

Addition from Ollie Clark

May be the same problem I was having (see below). I've put my solution in there.

Version 1.26.0 of Mediawiki with AuthRemoteUser prevents bureaucrats, sysops and bots from logging in
It looks like version 1.26.0 of Mediawiki prevents bureaucrats and sysops logging in if you use this extension. There are two ways to fix this.

The first option is to copy the variable  from the DefaultSettings.php and to overwrite the   for bureaucrats, sysops and bots with 0. This goes into the LocalSettings.php, like this:

$wgPasswordPolicy = array(       'policies' => array( 'bureaucrat' => array(                       'MinimalPasswordLength' => 8,                        'MinimumPasswordLengthToLogin' => 0,                        'PasswordCannotMatchUsername' => true,                ), 'sysop' => array(                       'MinimalPasswordLength' => 8,                        'MinimumPasswordLengthToLogin' => 0,                        'PasswordCannotMatchUsername' => true,                ), 'bot' => array(                       'MinimalPasswordLength' => 8,                        'MinimumPasswordLengthToLogin' => 0,                        'PasswordCannotMatchUsername' => true,                ), 'default' => array(                       'MinimalPasswordLength' => 1,                        'PasswordCannotMatchUsername' => true,                        'PasswordCannotMatchBlacklist' => true,                        'MaximalPasswordLength' => 4096,                ), ),       'checks' => array( 'MinimalPasswordLength' => 'PasswordPolicyChecks::checkMinimalPasswordLength', 'MinimumPasswordLengthToLogin' => 'PasswordPolicyChecks::checkMinimumPasswordLengthToLogin', 'PasswordCannotMatchUsername' => 'PasswordPolicyChecks::checkPasswordCannotMatchUsername', 'PasswordCannotMatchBlacklist' => 'PasswordPolicyChecks::checkPasswordCannotMatchBlacklist', 'MaximalPasswordLength' => 'PasswordPolicyChecks::checkMaximalPasswordLength', ), );

The second (cleaner) option is to fix this issue in the extension. We have to make the extension login with a password that has more than 0 characters: for example a space. A patch is attached here:

diff --git a/extensions/Auth_remoteuser/Auth_remoteuser.body.php b/extensions/Auth_remoteuser/Auth_remoteuser.body.php index 5fd48fd..3c8598a 100644 --- a/extensions/Auth_remoteuser/Auth_remoteuser.body.php +++ b/extensions/Auth_remoteuser/Auth_remoteuser.body.php @@ -287,7 +287,7 @@ class Auth_remoteuser extends AuthPlugin { // Submit a fake login form to authenticate the user. $params = new FauxRequest( array( 'wpName' => $username, -                   'wpPassword' => '', +                   'wpPassword' => ' ',  # Circumvent MinimumPasswordLengthToLogin 'wpDomain' => '', 'wpLoginToken' => $token, 'wpRemember' => '' JonasGroger (talk) 16:59, 4 December 2015 (UTC)

Addition from Qlymaxis : Thank you so much for this fix ! Work for me


 * This patch works for me too, on MediaWiki 1.26.2. Thanks Jonas! 136.159.16.240 19:27, 10 March 2016 (UTC)
 * MW 1.26.3 - Patch works for me --Hmos77 (talk) 15:40, 12 July 2016 (UTC)

Mediawiki 1.27.0
Starting from Mediawiki 1.27.0 (maybe even 1.26.3?) this extension throws a fatal error ("Call to undefined method LoginForm::authenticateUserData in /extensions/Auth_remoteuser/Auth_remoteuser.body.php on line 335").

This happens because the AuthManager has been rewritten. The upstream issue in Phabricator is https://phabricator.wikimedia.org/T110292

There is now a rewritten Auth_remoteuser to use the SessionProvider API. You can find it here: https://github.com/noris-network/mediawiki-extensions-sessionprovider-remoteuser

Feature Request: Fire Hook "UserLoggedIn"
To the authors of this extension: Would it be possible to fire the UserLoggedIn hook when a new session is being created?

Edit: Commited a patch - https://gerrit.wikimedia.org/r/383845


 * Tracking this now as T185391 -- Enst80 (talk) 17:44, 20 January 2018 (UTC)

Plugin not loading Group Permissions
The plugin is working correctly and I am able to log-in automatically. I have set up LDAP and want to set specific permissions for different user groups. The permissions are not pulling through when using the Auth_RemoteUser plugin but these work if you use the Manual Authentication through LDAP. Does any know of any issues with the setting of Permission Groups whilst using this plugin?
 * Please can you elaborate more on what you want to achieve? Which MW version are you using, how are you using the Auth_remoteuser extension? Right now (as of version 2.0.0) the extension does NOT support the setting of any group membership but it doesn't change existing group membership in MW also. If you have an already existing user and he is getting logged-in automatically, than all group membership which was set in MW before is still valid/active. If the extension creates a new user in MW first before logging-in him automatically, than you have to set the according group membership by any other process. This seems to me more like a feature request (setting of group membership with Auth_remoteuser) than a possible bug. Am i right? --Enst80 (talk) 19:02, 21 January 2018 (UTC)

Error logging?
Using Mediawiki version 1.30 and this extension version 2.0.0, I can see that the extension has logging statements but am unsure that these are actually doing anything.

For example, in 'UserNameSessionProvider.php' at line 245 it shows:

What I cannot see is where this would get logged. Any ideas?

Thanks.

--141.163.107.152 14:54, 5 February 2018 (UTC)


 * See section Howto Debug on this extensions documentation page: Use MediaWikis global  variable in your , then have a look at the created logfile for lines starting with  . --Enst80 (talk) 15:51, 5 February 2018 (UTC)

Thanks for that. I already had debugging enabled but was seeing nothing being logged. I added some more 'logger' statements, and it seems that (in my case) REMOTE_USER is not being set at all. My login requests basically just drop through the code, and return me to the login page. Perhaps a logger line could be added when no REMOTE_USER (etc) is found?

--141.163.107.152 16:57, 5 February 2018 (UTC)

apiupload.php not getting passed a user
Switching to this talk page as suggested. I've abandoned visual editor, I'm just trying to get wikieditor to work now. The 'embedded file' button for inserting images calls apiupload.php through uploadstash.php to get uploads but it throws an exception because it doesn't get a valid user or session or something, 'UploadStashNotLoggedInException'. wfDebug( "ApiUpload-user: ".$user->getId); returns a zero for the userId when auth_remoteuser is enabled, but works fine and returns the correct userId when auth_remoteuser is disabled. I've tried with the 2.0.1 version this morning and I've tried to follow the breadcrumbs but I don't know how to decipher the js stuff to see how the upload script gets called. Can you reproduce this behavior? If you can't reproduce, then this *might* be a server configuration issue.--TespSam (talk) 19:18, 19 March 2018 (UTC) I stared at my debug logs for days now and I think what's happening is that the _session token gets replaced three or four times when a page gets loaded up and I lose my user token or it doesn't match the expected one that uploadstash.php is looking for. I tried setting wgUser up in the extension, and it gets reset before I can use it in the upload wizard. Here's some log file for you: [session] SessionBackend "tfhnvmm3m5q93ha90nct9fo2e5hb2r8u" is unsaved, marking dirty in constructor [CryptRand] 0 bytes of randomness leftover in the buffer. [session] SessionBackend "qnlc0bmrb45toj7662g37leoc12on1n0" metadata dirty due to ID reset (formerly "tfhnvmm3m5q93ha90nct9fo2e5hb2r8u") [session] SessionBackend "qnlc0bmrb45toj7662g37leoc12on1n0" save: dataDirty=1 metaDirty=1 forcePersist=0 [cookie] setcookie: "mwdev51a2e67c_session", "qnlc0bmrb45toj7662g37leoc12on1n0", "0", "/", "", "", "1" [cookie] setcookie: "mwdev51a2e67cRemoteToken", "userFour", "1524254504", "/", "", "", "1" [cookie] setcookie: "mwdev51a2e67cUserID", "4", "1537214504", "/", "", "", "1" [cookie] setcookie: "mwdev51a2e67cUserName", "userFour", "1537214504", "/", "", "", "1" [cookie] setcookie: "mwdev51a2e67cToken", "0e0d34e0178fed70dcfbebeaf0f0f870", "1537214504", "/", "", "", "1" [cookie] already deleted setcookie: "forceHTTPS", "", "1490126504", "/", "", "", "1" [session] SessionBackend "qnlc0bmrb45toj7662g37leoc12on1n0" save: dataDirty=1 metaDirty=1 forcePersist=0 [cookie] already set setcookie: "mwdev51a2e67c_session", "qnlc0bmrb45toj7662g37leoc12on1n0", "0", "/", "", "", "1" [cookie] already set setcookie: "mwdev51a2e67cRemoteToken", "userFour", "1524254504", "/", "", "", "1" [cookie] already set setcookie: "mwdev51a2e67cUserID", "4", "1537214504", "/", "", "", "1" [cookie] already set setcookie: "mwdev51a2e67cUserName", "userFour", "1537214504", "/", "", "", "1" [cookie] already set setcookie: "mwdev51a2e67cToken", "0e0d34e0178fed70dcfbebeaf0f0f870", "1537214504", "/", "", "", "1" [cookie] already deleted setcookie: "forceHTTPS", "", "1490126504", "/", "", "", "1" [cookie] already set setcookie: "mwdev51a2e67c_session", "qnlc0bmrb45toj7662g37leoc12on1n0", "0", "/", "", "", "1" [cookie] already set setcookie: "mwdev51a2e67cRemoteToken", "userFour", "1524254504", "/", "", "", "1" [cookie] already set setcookie: "mwdev51a2e67cUserID", "4", "1537214504", "/", "", "", "1" [cookie] already set setcookie: "mwdev51a2e67cUserName", "userFour", "1537214504", "/", "", "", "1" [cookie] already set setcookie: "mwdev51a2e67cToken", "0e0d34e0178fed70dcfbebeaf0f0f870", "1537214504", "/", "", "", "1" [cookie] already deleted setcookie: "forceHTTPS", "", "1490126504", "/", "", "", "1" [session] SessionBackend "qnlc0bmrb45toj7662g37leoc12on1n0" Taking over PHP session [session] SessionBackend "qnlc0bmrb45toj7662g37leoc12on1n0" data dirty due to dirty: User->getName/User->load/User->loadFromSession/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty [session] SessionBackend "qnlc0bmrb45toj7662g37leoc12on1n0" data dirty due to dirty: User->getName/User->load/User->loadFromSession/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty [session] SessionBackend "qnlc0bmrb45toj7662g37leoc12on1n0" data dirty due to dirty: User->getName/User->load/User->loadFromSession/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty --TespSam (talk) 21:57, 21 March 2018 (UTC)


 * I don't see a line coming from Auth_remoteuser itself, something like "[session] Setting up auto login session for remote user name...". Are you sure, that the extension recognizes any ? Will try your setup in my test environment this weekend. Maybe i can reproduce it. But normally the API entry point should get the same environment as the main wiki when calling it with your browser, because using WikiEditor are just AJAX calls from within your browser. Regarding VisualEditor and Parsoid, thats another case, because Parsoid isn't calling the API from within your browser. It is its own process, so it must authenticate itself. Normally you can achieve this by giving read permission for anonymous users from localhost when Parsoid runs on the same machine as your wiki installation (or by specifying a   user for the   when , @see new example #7 in the configuration details of  ). -- Enst80 (talk) 23:06, 23 March 2018 (UTC)
 * I get "Setting up auto login session for remote user name 'userFour' (mapped to..." for a regular page load, but I get "Can't login remote user ' ' automatically. Given remote user name is not of type string or empty." when trying to do an upload from the WikiEditor Toolbar. Other than this problem, I appear to stay logged in just fine the whole time.--TespSam (talk) 14:30, 26 March 2018 (UTC)
 * api.php?action=query&meta=userinfo returns user "0" but alert(mw.user.getName) from inside the upload dialog returns correct username. --TespSam (talk) 19:19, 26 March 2018 (UTC)
 * Also, all of these problems go away when I turn off the extension and log in normally, so I'm apt to believe that it's a problem with the extension.--TespSam (talk) 16:19, 27 March 2018 (UTC)

MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProvider_session expires on 1969-12-31T23:59:59.000Z
when i look in my private wiki at the cookies, i see that MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProvider_session expires on 1969-12-31T23:59:59.000Z is this normal?


 * That's 1 second before 1970-01-01, which is  for a unix time stamp. The extension itself doesn't modify the expiry date of cookies in any way. It is using the settings coming from MW core. Did you specified   or   anywhere in your code (  or   maybe)? -- Enst80 (talk) 22:51, 23 March 2018 (UTC)