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)
 * Another solution is to grant initial admin rights with "createAndPromote.php" script. See Manual:CreateAndPromote.php Framillien 15:34, 13 August 2018 (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)
 * Just downgraded the extension to version 1.3.2 and things seem to work now.--TespSam (talk) 18:27, 27 March 2018 (UTC)
 * It's possible that your problem got solved by the last patch for T198928. --Enst80 (talk) 19:10, 20 July 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)

Showing real name or e-mail instead of username?
A few wiki admins used Extension:Auth remoteuser (thanks!) to integrate with a particular authentication system, so they have long numeric user-ID as usernames: "a little detail" as the possibility to show real names instead of user names in page history would surely help readability and cooperation... Is there a way or a configuration variable to enable that feature, something like $wgDisplayRealName = true / false ? Thank you! --Beriox 11:06, 26 April 2018 (UTC)


 * There are extensions regarding this aspect already. But normally i would expect something like this as a configuration option of the theme/skin used. If none of the former mentioned extensions do what you need, than maybe adjust the source directly: For displaying the realname instead of the username in the user personal url bar (upper right in vector skin) adjust the file   and replace the   with  . For adjusting the special page "RecentChanges/PageHistory" have a look at the container class in  . --Enst80 (talk) 19:21, 20 July 2018 (UTC)

Problem with Parsoid
We have Kerberos enabled for apache which provides for every page the user. However as parsoid was not providing these credentials when connecting to http://localhost/wiki/api.php, the create/edit would fail. Does anybody use this extension in a private wiki with parsoid and visual editor?
 * The example #7 has been added to the examples section of the parameter  for this specific use case --Enst80 (talk) 19:24, 20 July 2018 (UTC)

Sessions dropping seems Auth_remoteuser related
Running:
 * RHEL7
 * MediaWiki 1.30.0 (830bb58)
 * PHP 5.6.36 (apache2handler)
 * MariaDB 5.5.56-MariaDB
 * ICU 50.1.2
 * Elasticsearch 5.6.9
 * Auth_remoteuser 2.0.1

Also running:
 * CA Policy Agent for third party Access control and enterprise session header data.

When Ext:Auth_remoteuser is commented out, things run well.

When Ext:Auth_remoteuser is loaded I often get loss of session errors when I try to save a page.

Typical Trace on such an error looks like this: [caches] cluster: MemcachedPhpBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: MemcachedPhpBagOStuff, session: MemcachedPhpBagOStuff [caches] LocalisationCache: using store LCStoreCDB [MessageCache] MessageCache::load: Loading en... local cache is empty, got from global cache [DBReplication] Wikimedia\Rdbms\LBFactory::getChronologyProtector: using request info { "IPAddress": "139.88.115.249", "UserAgent": "Mozilla\/5.0 (Windows NT 6.1; WOW64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/66.0.3359.181 Safari\/537.36", "ChronologyProtection": false } [DBConnection] Wikimedia\Rdbms\LoadBalancer::openConnection: calling initLB before first connection. [DBConnection] Connected to database 0 at 'localhost'. [DBQuery] wiki_pbtracker BEGIN /* Wikimedia\Rdbms\Database::query (User::idFromName) */ [DBQuery] wiki_pbtracker SELECT /* User::idFromName */ user_id FROM `user` WHERE user_name = 'Rkevans' LIMIT 1 User: cache miss for user 2 [DBQuery] wiki_pbtracker SELECT /* User::loadFromDatabase */ user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount FROM `user` WHERE user_id = '2' LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* UserGroupMembership::getMembershipsForUser */ ug_user,ug_group,ug_expiry FROM `user_groups` WHERE ug_user = '2' User: loading options for user 2 from database. [DBQuery] wiki_pbtracker SELECT /* User::loadOptions */ up_property,up_value FROM `user_properties` WHERE up_user = '2' [CryptRand] mcrypt_create_iv generated 20 bytes of randomness. [CryptRand] 0 bytes of randomness leftover in the buffer. [CryptRand] mcrypt_create_iv generated 20 bytes of randomness. [CryptRand] 0 bytes of randomness leftover in the buffer. [session] Setting up auto login session for remote user name 'rkevans' (mapped to MediaWiki user 'Rkevans', currently active as MediaWiki user 'Rkevans'). [session] SessionBackend "75tdcvluuq37aube8p789dtjfsb1sfu2" is unsaved, marking dirty in constructor [CryptRand] mcrypt_create_iv generated 20 bytes of randomness. [CryptRand] 0 bytes of randomness leftover in the buffer. [session] SessionBackend "7lj0b9tjda5rg53fhu4194cjoedhikgk" metadata dirty due to ID reset (formerly "75tdcvluuq37aube8p789dtjfsb1sfu2") [session] SessionBackend "7lj0b9tjda5rg53fhu4194cjoedhikgk" save: dataDirty=1 metaDirty=1 forcePersist=0 [cookie] already deleted setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProvider_session", "", "1496271625", "/", "", "1", "1" [cookie] already deleted setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderUserID", "", "1496271625", "/", "", "1", "1" [cookie] already deleted setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderToken", "", "1496271625", "/", "", "1", "1" [cookie] already deleted setcookie: "forceHTTPS", "", "1496271625", "/", "", "", "1" [session] SessionBackend "7lj0b9tjda5rg53fhu4194cjoedhikgk" data dirty due to dirty: MediaWiki\Session\SessionManager->getSessionInfoForRequest/MediaWiki\Session\SessionManager->loadSessionInfoFromStore/MediaWiki\Extensions\Auth_remoteuser\UserNameSessionProvider->refreshSessionInfo/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty [session] SessionBackend "7lj0b9tjda5rg53fhu4194cjoedhikgk" data dirty due to dirty: MediaWiki\Session\SessionManager->getSessionInfoForRequest/MediaWiki\Session\SessionManager->loadSessionInfoFromStore/MediaWiki\Extensions\Auth_remoteuser\UserNameSessionProvider->refreshSessionInfo/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty [session] SessionBackend "7lj0b9tjda5rg53fhu4194cjoedhikgk" force-persist due to persist [session] SessionBackend "7lj0b9tjda5rg53fhu4194cjoedhikgk" save: dataDirty=1 metaDirty=1 forcePersist=1 [cookie] setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProvider_session", "7lj0b9tjda5rg53fhu4194cjoedhikgk", "0", "/", "", "1", "1" [cookie] setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderRemoteToken", "rkevans", "1530399625", "/", "", "1", "1" [cookie] setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderUserID", "2", "1543359625", "/", "", "1", "1" [cookie] setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderUserName", "Rkevans", "1543359625", "/", "", "1", "1" [cookie] setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderToken", "830c5bc1d39126c2bd9924da4bac6cb6", "1543359625", "/", "", "1", "1" [cookie] already deleted setcookie: "forceHTTPS", "", "1496271625", "/", "", "", "1" [session] SessionBackend "7lj0b9tjda5rg53fhu4194cjoedhikgk" save: dataDirty=1 metaDirty=1 forcePersist=1 [cookie] already set setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProvider_session", "7lj0b9tjda5rg53fhu4194cjoedhikgk", "0", "/", "", "1", "1" [cookie] already set setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderRemoteToken", "rkevans", "1530399625", "/", "", "1", "1" [cookie] already set setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderUserID", "2", "1543359625", "/", "", "1", "1" [cookie] already set setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderUserName", "Rkevans", "1543359625", "/", "", "1", "1" [cookie] already set setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderToken", "830c5bc1d39126c2bd9924da4bac6cb6", "1543359625", "/", "", "1", "1" [cookie] already deleted setcookie: "forceHTTPS", "", "1496271625", "/", "", "", "1" [cookie] already set setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProvider_session", "7lj0b9tjda5rg53fhu4194cjoedhikgk", "0", "/", "", "1", "1" [cookie] already set setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderRemoteToken", "rkevans", "1530399625", "/", "", "1", "1" [cookie] already set setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderUserID", "2", "1543359625", "/", "", "1", "1" [cookie] already set setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderUserName", "Rkevans", "1543359625", "/", "", "1", "1" [cookie] already set setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderToken", "830c5bc1d39126c2bd9924da4bac6cb6", "1543359625", "/", "", "1", "1" [cookie] already deleted setcookie: "forceHTTPS", "", "1496271625", "/", "", "", "1" [session] SessionBackend "7lj0b9tjda5rg53fhu4194cjoedhikgk" Taking over PHP session [session] SessionBackend "75tdcvluuq37aube8p789dtjfsb1sfu2" is unsaved, marking dirty in constructor [CryptRand] mcrypt_create_iv generated 20 bytes of randomness. [CryptRand] 0 bytes of randomness leftover in the buffer. [session] SessionBackend "v870opk8jd4arse3nt8mou9ibvegg59l" metadata dirty due to ID reset (formerly "75tdcvluuq37aube8p789dtjfsb1sfu2") [session] SessionBackend "v870opk8jd4arse3nt8mou9ibvegg59l" save: dataDirty=1 metaDirty=1 forcePersist=0 [cookie] setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProvider_session", "", "1496271625", "/", "", "1", "1" [cookie] setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderUserID", "", "1496271625", "/", "", "1", "1" [cookie] setcookie: "MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProviderToken", "", "1496271625", "/", "", "1", "1" [cookie] already deleted setcookie: "forceHTTPS", "", "1496271625", "/", "", "", "1" [smw] [mw.db] connection provider with {"read":-1,"write":-2} [session] SessionBackend "v870opk8jd4arse3nt8mou9ibvegg59l" data dirty due to dirty: User->getName/User->load/User->loadFromSession/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty [session] SessionBackend "v870opk8jd4arse3nt8mou9ibvegg59l" data dirty due to dirty: User->getName/User->load/User->loadFromSession/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty [session] SessionBackend "v870opk8jd4arse3nt8mou9ibvegg59l" data dirty due to dirty: User->getName/User->load/User->loadFromSession/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty [DBQuery] wiki_pbtracker SELECT /* WikiPage::pageData */ page_id,page_namespace,page_title,page_restrictions,page_is_redirect,page_is_new,page_random,page_touched,page_links_updated,page_latest,page_len,page_content_model FROM `page` WHERE page_namespace = '0' AND page_title = 'Main_Page' LIMIT 1 Title::getRestrictionTypes: applicable restrictions to Main Page are {edit,move} [ContentHandler] Created handler for wikitext: WikitextContentHandler [DBQuery] wiki_pbtracker SELECT /* Wikimedia\Rdbms\Database::selectField */ rev_id FROM `approved_revs` WHERE page_id = '62' LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* LocalIdLookup::lookupUserNames */ user_id,user_name FROM `user` WHERE user_name = 'Rkevans' User: loading options for user 2 from override cache. [DBConnection] Connected to database 0 at 'localhost'. [DBQuery] wiki_pbtracker SELECT /* SqlBagOStuff::getMulti */ keyname,value,exptime FROM `objectcache` WHERE keyname = 'wiki_pbtracker:echo:seen:alert:time:2' [DBQuery] wiki_pbtracker SELECT /* SqlBagOStuff::getMulti */ keyname,value,exptime FROM `objectcache` WHERE keyname = 'wiki_pbtracker:echo:seen:message:time:2' Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache->getParser Parser: using preprocessor: Preprocessor_DOM Unstubbing $wgPageFormsFormPrinter on call of $wgPageFormsFormPrinter::registerInputType from SFS\Hooks::onSemanticFormsSelectSetup Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions->__construct [caches] parser: EmptyBagOStuff [session] SessionBackend "v870opk8jd4arse3nt8mou9ibvegg59l" save: dataDirty=1 metaDirty=0 forcePersist=0 Article::view using parser cache: yes [DBQuery] wiki_pbtracker SELECT /* Revision::loadMutableFields */ rev_deleted,user_name FROM `revision`,`user` WHERE rev_id = '7647' AND (user_id = rev_user) LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* Revision::getTitle */ page_namespace,page_title,page_id,page_latest,page_is_redirect,page_len FROM `page`,`revision` WHERE (page_id=rev_page) AND rev_id = '7647' LIMIT 1 Article::view: doing uncached parse [Preprocessor] Loaded preprocessor output from cache (key: wiki_pbtracker:preprocess-xml:71ba162060ab14ebffa3560ad38d2179:0) [DBQuery] wiki_pbtracker SELECT /* Wikimedia\Rdbms\Database::selectRow */ approved_timestamp,approved_sha1 FROM `approved_revs_files` WHERE file_title = 'Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png' LIMIT 1 [Mime] MimeAnalyzer::loadFiles: loading mime types from /opt/htdocs/mediawiki/includes/libs/mime/mime.types [Mime] MimeAnalyzer::loadFiles: loading mime info from /opt/htdocs/mediawiki/includes/libs/mime/mime.info File::transform: Doing stat for mwstore://local-backend/local-thumb/4/47/Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png/1024px-Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png TransformationalImageHandler::doTransform: creating 1024x128 thumbnail at mwstore://local-backend/local-thumb/4/47/Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png/1024px-Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png using scaler im TransformationalImageHandler::doTransform: Transforming later per flags. File::transform: Doing stat for mwstore://local-backend/local-thumb/4/47/Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png/1536px-Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png TransformationalImageHandler::doTransform: creating 1536x193 thumbnail at mwstore://local-backend/local-thumb/4/47/Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png/1536px-Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png using scaler im TransformationalImageHandler::doTransform: Transforming later per flags. File::transform: Doing stat for mwstore://local-backend/local-thumb/4/47/Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png/1683px-Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png [FileOperation] FileBackendStore::getFileStat: File mwstore://local-backend/local-thumb/4/47/Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png/1683px-Wiki_Banner_-_NASA_PBS_Internal_Web_Site_(legacy).png does not exist. TransformationalImageHandler::doTransform: creating 1683x211 thumbnail at /opt/data-meza/tmp/transform_a4b5ecfcb55f.png using scaler im TransformationalImageHandler::doTransform: returning unscaled image [Preprocessor] Loaded preprocessor output from cache (key: wiki_pbtracker:preprocess-xml:71ba162060ab14ebffa3560ad38d2179:0) [DBQuery] wiki_pbtracker SELECT /* LinkHolderArray::replaceInternal */ page_id,page_len,page_is_redirect,page_latest,page_content_model,page_namespace,page_title FROM `page` WHERE (page_namespace = '0' AND page_title IN ('Plum_Brook_Yellow_Pages','Facility_Phone_Listing','Facility_Paging_Numbers','This_Week_at_Plum_Brook') ) [DBQuery] wiki_pbtracker SELECT /* PageProps::getProperties */ pp_page,pp_propname,pp_value FROM `page_props` WHERE pp_page = '1710' AND pp_propname = 'displaytitle' [DBQuery] wiki_pbtracker SELECT /* PageProps::getProperties */ pp_page,pp_propname,pp_value FROM `page_props` WHERE pp_page = '1711' AND pp_propname = 'displaytitle' [DBQuery] wiki_pbtracker SELECT /* PageProps::getProperties */ pp_page,pp_propname,pp_value FROM `page_props` WHERE pp_page = '1712' AND pp_propname = 'displaytitle' Title::getRestrictionTypes: applicable restrictions to Main Page are {edit,move} [DBQuery] wiki_pbtracker SELECT /* LinkCache::fetchPageRow */ page_id,page_len,page_is_redirect,page_latest,page_content_model FROM `page` WHERE page_namespace = '2' AND page_title = 'Rkevans' LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* ReviewHandler::getReviewStatus */ wl_notificationtimestamp FROM `watchlist` WHERE wl_user = '2' AND wl_namespace = '0' AND wl_title = 'Main_Page' LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* WatchedItemStore::loadWatchedItem */ wl_notificationtimestamp FROM `watchlist` WHERE wl_user = '2' AND wl_namespace = '0' AND wl_title = 'Main_Page' LIMIT 1 MediaWiki::preOutputCommit: primary transaction round committed MediaWiki::preOutputCommit: pre-send deferred updates completed MediaWiki::preOutputCommit: LBFactory shutdown completed [DBQuery] wiki_pbtracker SELECT /* PageProps::getProperties */ pp_page,pp_propname,pp_value FROM `page_props` WHERE pp_page = '62' AND pp_propname = 'displaytitle' [DBQuery] wiki_pbtracker SELECT /* UserWatchesQuery::getUserWatchStats */ u.user_name AS user_name,COUNT(*) AS num_watches,SUM( IF(w.wl_notificationtimestamp IS NULL, 0, 1) ) AS num_pending,SUM( IF(w.wl_notificationtimestamp IS NULL, 0, 1) ) * 100 / COUNT(*) AS percent_pending,MAX( TIMESTAMPDIFF(MINUTE, w.wl_notificationtimestamp, UTC_TIMESTAMP) ) AS max_pending_minutes,AVG( TIMESTAMPDIFF(MINUTE, w.wl_notificationtimestamp, UTC_TIMESTAMP) ) AS avg_pending_minutes,ROUND( IFNULL( EXP( -0.01 * SUM( IF(w.wl_notificationtimestamp IS NULL, 0, 1) ) ) EXP( -0.01 * FLOOR( AVG( TIMESTAMPDIFF( DAY, w.wl_notificationtimestamp, UTC_TIMESTAMP ) ) ) ), 1), 3) AS engagement_score FROM `watchlist` `w` LEFT JOIN `user` `u` ON ((u.user_id=w.wl_user)) LEFT JOIN `page` `p` ON ((p.page_namespace=w.wl_namespace AND p.page_title=w.wl_title)) LEFT JOIN `logging` `log` ON ((log.log_namespace = w.wl_namespace AND log.log_title = w.wl_title AND p.page_namespace IS NULL AND p.page_title IS NULL AND log.log_action = "delete")) WHERE w.wl_user=2 GROUP BY w.wl_user [DBQuery] wiki_pbtracker SELECT /* PageWatchesQuery::getPageWatchQuality */ SUM( user_watch_scores.engagement_score ) AS watch_quality FROM `watchlist` `w` RIGHT JOIN `page` `p` ON ((p.page_namespace=w.wl_namespace AND p.page_title=w.wl_title)) LEFT JOIN ( SELECT w2.wl_user AS user_name, ( ROUND( IFNULL( EXP( -0.01 * SUM( IF(w2.wl_notificationtimestamp IS NULL, 0, 1) ) ) EXP( -0.01 * FLOOR( AVG( TIMESTAMPDIFF( DAY, w2.wl_notificationtimestamp, UTC_TIMESTAMP ) ) ) ), 1), 3) ) AS engagement_score

FROM watchlist AS w2 GROUP BY w2.wl_user

) `user_watch_scores` ON ((user_watch_scores.user_name = w.wl_user)) WHERE p.page_namespace = '0' AND p.page_title = 'Main_Page' GROUP BY p.page_title, p.page_namespace LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* PageScore::getNumReviews */ COUNT(*) AS num_reviews FROM `watchlist` WHERE (wl_notificationtimestamp IS NULL) AND wl_namespace = '0' AND wl_title = 'Main_Page' LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* LinkBatch::doQuery (for Skin::preloadExistence) */ page_id,page_len,page_is_redirect,page_latest,page_content_model,page_namespace,page_title FROM `page` WHERE (page_namespace = '2' AND page_title = 'Rkevans') OR (page_namespace = '3' AND page_title = 'Rkevans') OR (page_namespace = '1' AND page_title = 'Main_Page') OR (page_namespace = '4304' AND page_title IN ('Privacy_policy','About','General_disclaimer') ) [DBQuery] wiki_pbtracker SELECT /* Title::getCascadeProtectionSources */ pr_page,page_namespace,page_title,pr_expiry,pr_type,pr_level FROM `templatelinks`,`page_restrictions`,`page` WHERE tl_namespace = '0' AND tl_title = 'Main_Page' AND (tl_from=pr_page) AND pr_cascade = '1' AND (page_id=pr_page) User::getBlockedStatus: checking... [DBQuery] wiki_pbtracker SELECT /* Block::newLoad */ ipb_id,ipb_address,ipb_by,ipb_by_text,ipb_timestamp,ipb_auto,ipb_anon_only,ipb_create_account,ipb_enable_autoblock,ipb_expiry,ipb_deleted,ipb_block_email,ipb_allow_usertalk,ipb_parent_block_id,ipb_reason AS `ipb_reason_text`,NULL AS `ipb_reason_data`,NULL AS `ipb_reason_cid` FROM `ipblocks` WHERE ipb_address = 'Rkevans' [DBQuery] wiki_pbtracker SELECT /* User::checkNewtalk */ user_id FROM `user_newtalk` WHERE user_id = '2' LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* PageProps::getProperties */ pp_page,pp_propname,pp_value FROM `page_props` WHERE pp_page = '55' AND pp_propname = 'displaytitle' [DBQuery] wiki_pbtracker SELECT /* EchoEventMapper::fetchUnreadByUserAndPage */ * FROM `echo_event` INNER JOIN `echo_notification` ON ((notification_event=event_id)) INNER JOIN `echo_target_page` ON ((etp_event=event_id)) WHERE event_deleted = '0' AND notification_user = '2' AND notification_read_timestamp IS NULL AND etp_page = '62' [DBQuery] wiki_pbtracker SELECT /* LocalIdLookup::lookupUserNames */ user_id,user_name FROM `user` WHERE user_name = 'Rkevans' [DBQuery] wiki_pbtracker SELECT /* LocalIdLookup::lookupUserNames */ user_id,user_name FROM `user` WHERE user_name = 'Rkevans' [DBQuery] wiki_pbtracker SELECT /* LocalIdLookup::lookupUserNames */ user_id,user_name FROM `user` WHERE user_name = 'Rkevans' [DBQuery] wiki_pbtracker SELECT /* LocalIdLookup::lookupUserNames */ user_id,user_name FROM `user` WHERE user_name = 'Rkevans' [DBQuery] wiki_pbtracker SELECT /* LocalIdLookup::lookupUserNames */ user_id,user_name FROM `user` WHERE user_name = 'Rkevans' [DBQuery] wiki_pbtracker SELECT /* LocalIdLookup::lookupUserNames */ user_id,user_name FROM `user` WHERE user_name = 'Rkevans' [DBQuery] wiki_pbtracker SELECT /* EchoUserNotificationGateway::getCappedNotificationCount */ COUNT(*) AS `rowcount` FROM (SELECT 1 FROM `echo_notification` LEFT JOIN `echo_event` ON ((notification_event=event_id)) WHERE notification_user = '2' AND notification_read_timestamp IS NULL AND event_deleted = '0' AND event_type IN ('welcome','thank-you-edit','article-reminder','edit-thank','flow-thank','flow-new-topic','flow-post-reply','flow-topic-renamed','flow-summary-edited','flow-description-edited','flow-enabled-on-talkpage','flow-topic-resolved') LIMIT 100 ) `tmp_count` [DBQuery] wiki_pbtracker SELECT /* EchoUserNotificationGateway::getCappedNotificationCount */ COUNT(*) AS `rowcount` FROM (SELECT 1 FROM `echo_notification` LEFT JOIN `echo_event` ON ((notification_event=event_id)) WHERE notification_user = '2' AND notification_read_timestamp IS NULL AND event_deleted = '0' AND event_type IN ('edit-user-talk','reverted','mention','mention-failure','mention-failure-too-many','mention-success','user-rights','emailuser','foreign','flowusertalk-new-topic','flowusertalk-post-reply','flow-post-edited','flowusertalk-post-edited','flowusertalk-topic-renamed','flowusertalk-summary-edited','flowusertalk-description-edited','flow-mention','flowusertalk-topic-resolved','flow-mention-failure-too-many') LIMIT 100 ) `tmp_count` [DBQuery] wiki_pbtracker SELECT /* EchoNotificationMapper::fetchByUserInternal */ * FROM `echo_notification` LEFT JOIN `echo_event` ON ((notification_event=event_id)) WHERE notification_user = '2' AND event_type IN ('welcome','thank-you-edit','article-reminder','edit-thank','flow-thank','flow-new-topic','flow-post-reply','flow-topic-renamed','flow-summary-edited','flow-description-edited','flow-enabled-on-talkpage','flow-topic-resolved') AND event_deleted = '0' AND notification_read_timestamp IS NULL ORDER BY notification_timestamp DESC, notification_event DESC LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* EchoNotificationMapper::fetchByUserInternal */ * FROM `echo_notification` LEFT JOIN `echo_event` ON ((notification_event=event_id)) WHERE notification_user = '2' AND event_type IN ('edit-user-talk','reverted','mention','mention-failure','mention-failure-too-many','mention-success','user-rights','emailuser','foreign','flowusertalk-new-topic','flowusertalk-post-reply','flow-post-edited','flowusertalk-post-edited','flowusertalk-topic-renamed','flowusertalk-summary-edited','flowusertalk-description-edited','flow-mention','flowusertalk-topic-resolved','flow-mention-failure-too-many') AND event_deleted = '0' AND notification_read_timestamp IS NULL ORDER BY notification_timestamp DESC, notification_event DESC LIMIT 1 Title::getRestrictionTypes: applicable restrictions to Main Page are {edit,move} Title::getRestrictionTypes: applicable restrictions to Main Page are {edit,move} [DBQuery] wiki_pbtracker SELECT /* Wikimedia\Rdbms\Database::select */ pp_value FROM `page_props` WHERE pp_page = '62' AND pp_propname IN ('PFDefaultForm','SFDefaultForm') [DBQuery] wiki_pbtracker SELECT /* PFValuesUtils::getCategoriesForPage */ DISTINCT cl_to FROM `categorylinks` WHERE cl_from = '62' [DBQuery] wiki_pbtracker SELECT /* LinkCache::fetchPageRow */ page_id,page_len,page_is_redirect,page_latest,page_content_model FROM `page` WHERE page_namespace = '4304' AND page_title = 'Main' LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* Wikimedia\Rdbms\Database::select */ pp_value FROM `page_props` WHERE pp_page = '0' AND pp_propname IN ('PFDefaultForm','SFDefaultForm') LocalisationCache::isExpired(upload): cache missing, need to make one [DBQuery] wiki_pbtracker SELECT /* User::idFromName */ user_id FROM `user` WHERE user_name = 'Rkevans' LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* User::loadFromDatabase */ user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount FROM `user` WHERE user_id = '2' LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* UserGroupMembership::getMembershipsForUser */ ug_user,ug_group,ug_expiry FROM `user_groups` WHERE ug_user = '2' Title::getRestrictionTypes: applicable restrictions to Main Page are {edit,move} [DBQuery] wiki_pbtracker SELECT /* User::idFromName */ user_id FROM `user` WHERE user_name = 'Rkevans' LIMIT 1 [DBQuery] wiki_pbtracker SELECT /* User::loadFromDatabase */ user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount FROM `user` WHERE user_id = '2' LIMIT 1 User: loading options for user 2 from database. [DBQuery] wiki_pbtracker SELECT /* User::loadOptions */ up_property,up_value FROM `user_properties` WHERE up_user = '2' [CryptRand] mcrypt_create_iv generated 16 bytes of randomness. [CryptRand] 0 bytes of randomness leftover in the buffer. [session] SessionBackend "v870opk8jd4arse3nt8mou9ibvegg59l" data dirty due to dirty: User->getEditToken/User->getEditTokenObject/MediaWiki\Session\Session->getToken/MediaWiki\Session\Session->set/MediaWiki\Session\SessionBackend->dirty [session] SessionBackend "v870opk8jd4arse3nt8mou9ibvegg59l" save: dataDirty=1 metaDirty=0 forcePersist=0

Please help

Here are what I think are the salient lines of the Trace log: [session] Setting up auto login session for remote user name 'rkevans' (mapped to MediaWiki user 'Rkevans', currently active as MediaWiki user 'Rkevans'). User: loading options for user 2 from override cache. . . . User: loading options for user 2 from override cache. . . . EditPage::importFormData: Failed token check; forcing preview . ..

Here's what the page shows: Preview Sorry! We could not process your edit due to a loss of session data.

You might have been logged out. Please verify that you're still logged in and try again. If it still does not work, try logging out and logging back in, and check that your browser allows cookies from this site.

seems to be the dead body.. but where is the smoking gun?

I think the issue is in Auth remote user not creating mediawiki session cookies (it creates them for a new user but not for an existing user). This means that when the API for example wants to validate a csrf token it fails because it cannot find the right session


 * 2018-07-17-User:revansx -- For my part, the issue is solved. To my amazement, the solution was as simple as commenting out 1 line of code per this patch: https://gerrit.wikimedia.org/r/445775

"First Save" bug with MW 1.30 and AuthRU 2.0.2

 * 2018-06-04-User:revansx -- I'm having this same issue that is discussed HERE on my 1.30 wiki running AuthRU v2.0.2 and CA Policy Agent.
 * I have analyzed the HTTP_COOKIE variable in my session header at various stages of the process and I agree that the issue seems to be related to when the session cookie is created.
 * Please see the following screenshot for details:
 * 2018-06-04--09-51-53--screenshot-rkevans001.png
 * I would really appreciate some help in implementing the hack that adds:  in front of   to
 * However, the above hack seems to be outdated.
 * nowhere in  can I find   "exactly"
 * appears 7 times in
 * Where should I add the  hack?
 * Should it be modified for MW 1.30 user.php? and if so, How?

Did you solve this issue? it seems to me that the session cookies are created by the isLoggedin Call but then somehow these are deleted, I still have to figure out how/why
 * 2018-07-17-User:revansx -- For my part, the issue is solved. To my amazement, the solution was as simple as commenting out 1 line of code per this patch: https://gerrit.wikimedia.org/r/445775


 * 2018-07-26-Anonym -- I also had to remove these two settings to make it work:
 * 1) $wgMainCacheType = CACHE_ACCEL;
 * 2) $wgMemCachedServers = [];

Auth_remoteuser setting and then deleting session cookies for existing users
I noticed that auth_remoteuser sessino provider is setting and then deleting session cookies for existing users. Specifically it deletes and never set back the cookies: Token, _session and UserID. This results in issues when validating csrf token against the API making impossible to use visual-editor. (while the default editor, on sumbmit, detects the missing cookies, throws an error and re-set them correctly).

I am using MW 1.30 and auth_remoteuser 2.0.1

A logfile can be found here: https://pastebin.com/43TBnvsa


 * I think this got solved by the last patch for T198928 too. --Enst80 (talk) 19:27, 20 July 2018 (UTC)

page forms loose edits when session expires
2018-07-25 -- I'm using Auth_RemoteUser as an immutable session provider in the following environment
 * MediaWiki 1.30.0 (830bb58)
 * Auth_remoteuser 2.0.1 (0af2823) 16:22, 24 April 2018
 * Page Forms 4.3 (c35e352) 13:50, 14 March 2018

When a user's session times-out before they SAVE during form page edit (ala 'action=formedit'), the page form looses the user's edits in the process of having a new session created. This does not happen with a normal edit (action=edit), only with form edits.

There has been talk about this problem in the past[0] and I'm wondering if the fix has been verified for users using AuthRemoteUser with an immutable session provider configuration.

[0] https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Archive_January_2015#Problem_with_losing_session_data_while_submitting_form

-Rich


 * Just to be sure, can you use  please instead of "...Auth_remoteuser 2.0.1..." (0af2823) (This commit hash is before the fix and i don't know if you applied the fix for T198928 on your own ;-) ). Anyways, i tested your settings with Extension:PageForms by using the   to simulate a session timeout and i get the "due to lost session data"-error every time for every version of Auth_remoteuser. If the session did not timed out, then it works for the fixed version, but not before. So yes, the fix for T198928 also made "...action=formedits..." possible. But did you mean with "..the form looses edits..." that you would expect it to be saved even when the session timed out (then maybe extend the session lifespan with setting the   accordingly; or would you expect Auth_remoteuser to retain the session in any case)? Or did you mean that the form itself looses its content (but this should be a browser specific behavior, because in my firefox i get the "due to lost session data"-error but still have my forms filled with the data i putted in before)? --Enst80 (talk) 08:23, 26 July 2018 (UTC)

Session providers have little effect on how session timeouts are handled; normally HTMLForm sets the form fields to the submitted value even when the submission is not valid (because the session timed out and the CSRF token could not be validated). Maybe the PageForms extension's form handling interferes with that somehow. --Tgr (WMF) (talk) 10:30, 26 July 2018 (UTC)


 * Rich -> Enst80 - 1) Yes, I manually implemented the most recent fix myself without updating properly. So I have updated to 2.1.0 now and am testing. Results soon. 2) "the form looses edits" meaning, "the form itself looses the unsaved contents and the result from trying to save is that the form has been refreshed to the previous saved version and the users intended updates are all gone from the entire browser page. Hitting save again will not help as the user's intended edits have not been carried over into the refreshed formedit page." -- fingers crossed on this formal update having the fix. If not, I will be eager to explore what the difference might be in our setups since yours carries the user's unsaved work through the session renewal.


 * Rich -> Tgr - if you are right and this is an issue with the way PF interacts with CSRF tokens, do you think it might be limited to my security environment being based on having an immutable session provider?

update -- updating to version 2.1.0 did not solve the problem. For me the problem is replicated as follows:
 * 1) click 'edit with form' on a form page.
 * 2) make some edits
 * 3) wait > 15 mintes
 * 4) click save
 * 5) observe that page redirects to remote immutable session provider with call-back to the referring page
 * 6) observe that the page refreshes with the renewed session and returns the client to the page in the form edit mode, newly called with no pending edits.
 * 7) observe user anger at lost data.

issue with PF and remote session re-validation?
It seems to me that the problem may be the difference between the way a standard edit and a form edit cache the pending edit while the browser is redirected to the remote session provided for re-authentication.. For some reason, pending changes from a standard edit survives the brief redirect to the remote session providers re-validation page, and the pending edits from a form edit do not. Could this be difference in the way that MW and PF cache the the POST data upon a save operation? (if so, this is not an Auth_RemoteUser issue)

MediaWiki 1.31 compatibility?
Has this been tested on MediaWiki 1.31 yet?

Multiple authentication
I want to set up the Auth_remoteuser plugin, I want to set it up with a possible double authentication: 1 - Verification in my AD if the user is present and at the rights If the authentication is successful, we have the same 2 - Otherwise, return to the login page

My problem is that I can put either one or the other but not the 2.

In my use, we are a computer team and will use the wiki for our technical docs. Only users of the IT team must have access, automatically to the server whith ntlm. When we are traveling, we would have to be able to access the Wiki without using the ntlm function and thus, by authenticating.

Does this plugin allow this operation?

Thanks

thank you in advance for your return,

MW 1.31 - logout token always failing
Hello,

With MW 1.31.0 we have been using Shibboleth single sign-on (SSO) with the Auth_remoteuser extension with no problems. We provide a customised 'login' and 'logout' URL for users. I am moving the service to a new server, and thought I would update MW to 1.31.2 at the same time. (It's a minor release, so no database changes. It should be relatively straight forward.)

However, it seems that between 1.31.0 and 1.31.2 an extra step has been introduced to the logout process to cater for CSRF prevention. To do this an extra 'logoutToken' parameter is used. I have modified our logout URL to cater for this, but it always shows the user the 'Log out failed due to session error. Please try again.' message. (This is annoying for the users. It's another step to go through just to logout.)

The above error indicates that the passed 'logoutToken' parameter is recognized, it just doesn't match the one the server thinks it has.

If I use the MW provided login/logout mechanism, then the logout URL is shown as:

Our customized user URL is:

In effect this takes the user to the Shibboleth logout, and then performs the 'return' to take the user to the MW logout via the special logout page (so that part should basically be the same as the MW logout URL).

The URL is constructed using:

Basically, this worked fine before (MW 1.31.0). We just added the "'%26logoutToken=' . urlencode($wgUser->getEditToken('logoutToken'))" on the end for MW 1.31.2

I am now a bit stuck as I cannot see what is causing the problem. The 'getEditToken' works (the parameter appears), and as far as I can tell should be returning the token the system is using. So it should match what the special logout page expects.

Anyone any ideas about this?

Thanks, John.

It turns out that at this stage the user has, in effect, logged out so the token is just '+/'.

To avoid the '+' character being interpreted as a space in the URL, all that is required to be added to the logout URL is '%26logoutToken=%252B%5C'.