Extension talk:Auth remoteuser/Archive
Add topicIf you have errors, please check m:User talk:Otheus/Auto Login via REMOTE USER for potential solution.
Extension has been refactored
[edit]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
[edit]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
<font color="red">$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 );</font>
}
if ( isset( $wgAuthRemoteuserMail ) ) {
$user->setEmail( $wgAuthRemoteuserMail );
} elseif ( isset( $wgAuthRemoteuserMailDomain ) ) {
$user->setEmail( <font color="red">$emailname</font> . '@' . $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
<font color="red">$username = strtolower( $_SERVER['REMOTE_USER'] );
$username = str_replace( "$wgAuthRemoteuserDomain\\", "", $username );</font>
$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
[edit]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)
$_SERVER['REDIRECT_REMOTE_USER']
[edit]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?
[edit]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
Wiki family - single login for multiple databases
[edit]I have created a wiki family to have multiple languages (like Wikipedia: en.site/wiki, fr.site/wiki) with a separate db and a sub-site for each language. Credentials are asked each time a user follows to another language sub site. So, users enter the same credentials again and again. Is it possible to request login just once for all sub-sites (sub-domains): en.site/wiki, fr.site/wiki ?..
Auto login locally?
[edit]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
[edit]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
[edit]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
[edit]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
[edit]I'm using the extension with Mediawiki 1.15.1 and Apache 2.2.11 with SunAM authentication.
Problems with name normalization and patch
[edit]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?
[edit]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
[edit]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?
[edit]How exactly is this extension used? Are there examples?
Gotcha: WikiSysop login
[edit]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
[edit]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
[edit]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.
- I changed the line $username = ""; to $username = getenv("username");
E-mail address as User Name
[edit]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
[edit]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.)
<?php
// vim:sw=2:softtabstop=2:textwidth=80
//
// This program is free software: you can redistribute it and/or modify it
// under the terms of the GNU General Public License as published by the Free
// Software Foundation, either version 2 of the License, or (at your option)
// any later version.
//
// This program is distributed in the hope that it will be useful, but WITHOUT
// ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
// FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
// more details.
//
// You should have received a copy of the GNU General Public License along with
// this program. If not, see <http://www.gnu.org/licenses/>.
//
// Copyright 2006 Otheus Shelling
// Copyright 2007 Rusty Burchfield
// Copyright 2009 James Kinsman
// Copyright 2010 Daniel Thomas
// Copyright 2010 Ian Ward Comfort
// Copyright 2011 Zachary Bedell <zac at the bedells dot org>
//
// In 2009, the copyright holders determined that the original publishing of this code
// under GPLv3 was legally and logistically in error, and re-licensed it under GPLv2.
//
// See http://www.mediawiki.org/wiki/Extension:AutomaticREMOTE_USER
//
// Adapted by Rusty to be compatible with version 1.9 of MediaWiki
// Optional settings from Emmanuel Dreyfus
// Adapted by VibroAxe (James Kinsman) to be compatible with version 1.16 of MediaWiki
// Adapted by VibroAxe (James Kinsman) to allow domain substitution for Integrated Windows Authentication
// Adapted by drt24 (Daniel Thomas) to add the optional $wgAuthRemoteuserMailDomain and remove hardcoding
// of permissions for anonymous users.
// Adapted by Ian Ward Comfort to detect mismatches between the session user and REMOTE_USER
// Adapted by Zachary Bedell to replicate LDAP groups from webserver environment variables.
//
// Add these lines to your LocalSettings.php
//
// /* Optional settings */
// $wgAuthRemoteuserAuthz = true; /* Your own authorization test */
// $wgAuthRemoteuserName = $_SERVER["AUTHENTICATE_CN"]; /* User's name */
// $wgAuthRemoteuserMail = $_SERVER["AUTHENTICATE_MAIL"]; /* User's Mail */
// $wgAuthRemoteuserNotify = false; /* Do not send mail notifications */
// $wgAuthRemoteuserDomain = "NETBIOSDOMAIN"; /* Remove NETBIOSDOMAIN\ from the beginning or @NETBIOSDOMAIN at the end of a IWA username */
// /* User's mail domain to append to the user name to make their email address */
// $wgAuthRemoteuserMailDomain = "example.com";
//
// // Setup replication of LDAP groups from the webserver (requires server configuration -- see below)
// $wgAuthRemoteuserGroups = $_SERVER['AUTHENTICATE_MEMBEROF']; // Web server environment variable containing list of LDAP groups
// $wgAuthRemoteuserGroupRegex = '/CN=([^,]+),[^;]*;?/'; // Regular expression to extract simple group names from LDAP DN's
// $wgAuthRemoteuserOverwriteLocalGroups = true; // to remove existing groups from wm database when they're removed from AD.
//
// // Don't let anonymous people do things...
// $wgGroupPermissions['*']['createaccount'] = false;
// $wgGroupPermissions['*']['read'] = false;
// $wgGroupPermissions['*']['edit'] = false;
//
// /* This is required for Auth_remoteuser operation
// require_once('extensions/Auth_remoteuser.php');
// $wgAuth = new Auth_remoteuser();
//
// The constructor of Auth_remoteuser registers a hook to do the automatic
// login. Storing the Auth_remoteuser object in $wgAuth tells mediawiki to use
// that object as the AuthPlugin. This way the login attempts by the hook will
// be handled by us.
//
// You probably want to edit the initUser function to set the users real name
// and email address properly for your configuration.
//
//
// LDAP Group Replication Support
//
// This exension can optionally extract LDAP groups from an environment variable provided by your web server. This will
// usually require some degree of server-level configuration and has currently only been tested on Apache against Active Directory.
//
// $wgAuthRemoteuserGroups specifies the list of groups, usually extracted from a $_SERVER[] scope variable. Format of this
// string is relatively flexible and can be dealt with using a regular expression.
//
// $wgAuthRemoteuserGroupRegex is an optional regular expression which extracts simple group names from full
// Distinguished Names provided by LDAP. The regex should contain one grouping expression (parenthesis) which should match the
// simple name of the group as will be used in MediaWiki's database. There are some potential problems with this approach in
// that it assumes your group simple names are equivalent to some portion of the DN. This may not be the case; but this may also
// not be a problem so long as the identifiers are unique and meaningul enough to exist in MediaWiki's database.
// These extracted simple names will only be used in the MW database, and the association back to LDAP will always
// be done by the full DN (assuming that's what your server puts in this field to begin with).
//
// It's also possible that a server might just put simple names into this wgAuthRemoteuserGroups field OR that you
// might write some code to populate wgAuthRemoteuserGroups with a more intelligent algorithm. If wgAuthRemoteuserGroups
// contains a comma separated list of simple names, then you can omit the regex completely.
//
// If the regex is omitted, the following behavior is used: If the contents of wgAuthRemoteuserGroups include any semicolons,
// it is assumed to be a list of LDAP DN's. The strings are split on the semicolons, trimmed, and used as-is (IE full DN's
// for group names). If no semicolons are present, then the string is split on commas and treated as is.
//
// wgAuthRemoteuserOverwriteLocalGroups controls whether exiting groups will be REMOVED from the MW database if they're
// not found in LDAP. This can be handy to allow removing people from groups via AD, but it makes it impossible to store
// any group information locally to MW that differs from AD.
//
// Apache Configuration:
//
// Assuming using Apache and Active Directory, the following Apache configuration should allow group replication:
//
// <Directory /path/to/mediawiki> # Could do "<Location /mediawiki>" instead
// AuthBasicProvider ldap
// AuthUserFile /dev/null
// AuthName "HTTP Auth Realm Name"
// AuthLDAPBindDN "user-who-can-search-ldap@my.domain.com"
// AuthLDAPBindPassword userspassword
// AuthLDAPURL ldaps://ldap-server:636/DC=my,DC=domain,DC=com?sAMAccountName,displayName,givenName,sn,mail,memberOf?sub?(objectClass=user)
// # The extra attributes (displayName...memberOf) after sAMAccountName tell Apache to populate environment
// # variables with the contents of those LDAP attributes. That lets this extension access those values without
// # requiring additional LDAP queries.
// AuthLDAPGroupAttribute member
// AuthLDAPGroupAttributeIsDN on
// AuthType Basic
//
// Require valid-user
//
// # Optionally require all MediaWiki users to be present in some LDAP group or be denied completely:
// Require ldap-group CN=WikiUsers,OU=Groups,DC=my,DC=domain,DC=com
//
// # Optionally force SSL to protect AD passwords:
// RewriteEngine On
// RewriteCond %{HTTPS} off
// RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=permanent,L]
// </Directory>
//
// The following LocalSettings.php configuration coupled with the above should work against ActiveDirectory:
// $wgAuthRemoteuserGroups = $_SERVER['AUTHENTICATE_MEMBEROF'];
// $wgAuthRemoteuserGroupRegex = '/CN=([^,]+),[^;]*;?/'; // Uses the CN portion of the DN as the simple name
// $wgAuthRemoteuserOverwriteLocalGroups = true;
//
// Assuming you had an LDAP group like the following for wiki administrators:
// CN=WikiAdmins,OU=Groups,DC=my,DC=domain,DC=com
// The regex would result in any members of that group in AD being added to a MediaWiki group named 'WikiAdmins' on login.
// You then might want to include something like the following in your LocalSettings.php to grant them admin rights:
//
// $wgAddGroups['WikiAdmins'] = true;
// $permsSysop = array(
// 'block', 'createaccount', 'editinterface', 'editusercss', 'edituserjs', 'importupload',
// 'move-rootuserpages', 'proxyunbannable', 'ipblock-exempt', 'blockemail', 'apihighlimits',
// 'noratelimit', 'versiondetail', 'mergehistory', 'userrights', 'siteadmin',
// 'delete', 'bigdelete', 'undelete', 'import', 'move', 'move-subpages', 'patrol', 'autopatrol',
// 'protect', 'rollback', 'trackback', 'reupload', 'reupload-shared', 'movefile', 'editprotected',
// 'deletedhistory', 'deletedtext', 'upload', 'reupload-own', 'unwatchedpages', 'upload_by_url',
// 'browsearchive', 'edit', 'createpage', 'createtalk', 'minoredit',
// 'autoconfirmed', 'emailconfirmed'
// );
// foreach($permsSysop as $perm) {
// $wgGroupPermissions['WikiAdmins'][$perm] = true;
// }
//
// You can also assign different combinations of rights to (for example) a WikiEditors group.
//
//Extension credits that show up on Special:Version
$wgExtensionCredits['other'][] = array(
'name' => 'AutomaticREMOTE USER',
'version' => '1.1.3',
'author' => array('Otheus Shelling', 'Rusty Burchfield', 'James Kinsman', 'Daniel Thomas', 'Ian Ward Comfort', "Zachary Bedell"),
'url' => 'http://www.mediawiki.org/wiki/Extension:AutomaticREMOTE_USER',
'description' => 'Automatically logs users using the REMOTE_USER environment variable.',
);
//We must allow zero length passwords. This extension does not work in MW 1.16 without this.
$wgMinimalPasswordLength = 0;
// The Auth_remoteuser class is an AuthPlugin so make sure we have this
// included.
require_once('AuthPlugin.php');
/**
* This hook is registered by the Auth_remoteuser constructor. It will be
* called on every page load. It serves the function of automatically logging
* in the user. The Auth_remoteuser class is an AuthPlugin and handles the
* actual authentication, user creation, etc.
*
* Details:
* 1. Check to see if the user has a session and is not anonymous. If this is
* true, check whether REMOTE_USER matches the session user. If so, we can
* just return; otherwise we must logout the session user and login as the
* REMOTE_USER.
* 2. If the user doesn't have a session, we create a login form with our own
* fake request and ask the form to authenticate the user. If the user does
* not exist authenticateUserData will attempt to create one. The login form
* uses our Auth_remoteuser class as an AuthPlugin.
*
* Note: If cookies are disabled, an infinite loop /might/ occur?
*/
function Auth_remote_user_hook() {
global $wgUser;
global $wgRequest;
global $_REQUEST;
global $wgAuthRemoteuserDomain;
// For a few special pages, don't do anything.
$title = $wgRequest->getVal('title');
if (($title == Title::makeName(NS_SPECIAL, 'UserLogout')) ||
($title == Title::makeName(NS_SPECIAL, 'UserLogin'))) {
return;
}
//Process the username if required
if (!isset($_SERVER['REMOTE_USER'])){
return;
}
if (isset($wgAuthRemoteuserDomain) && strlen($wgAuthRemoteuserDomain)) {
$username = str_replace("$wgAuthRemoteuserDomain\\","",$_SERVER['REMOTE_USER']);
$username = str_replace("@$wgAuthRemoteuserDomain","",$username);
} else {
$username = $_SERVER['REMOTE_USER'];
}
// Check for valid session
$user = User::newFromSession();
if (!$user->isAnon()) {
if ($user->getName() == Auth_remoteuser::getCanonicalName($username)) {
return; // Correct user is already logged in.
} else {
$user->doLogout(); // Logout mismatched user.
}
}
// Copied from includes/SpecialUserlogin.php
if(!isset($wgCommandLineMode) && !isset($_COOKIE[session_name()])) {
wfSetupSession();
}
// If the login form returns NEED_TOKEN try once more with the right token
$tryagain=false;
$trycount=0;
$token = '';
do
{
$tryagain=false;
// Submit a fake login form to authenticate the user.
$params = new FauxRequest(array(
'wpName' => $username,
'wpPassword' => '',
'wpDomain' => '',
'wpLoginToken' => $token,
'wpRemember' => ''
));
// Authenticate user data will automatically create new users.
$loginForm = new LoginForm($params);
$result = $loginForm->authenticateUserData();
switch ($result) {
case LoginForm :: SUCCESS :
$wgUser->setOption('rememberpassword', 1);
$wgUser->setCookies();
break;
case LoginForm :: NEED_TOKEN:
$token = $loginForm->getLoginToken();
$tryagain=($trycount==0);
break;
case LoginForm :: WRONG_TOKEN:
$errormessage = 'WrongToken';
break;
case LoginForm :: NO_NAME :
$errormessage = 'NoName';
break;
case LoginForm :: ILLEGAL :
$errormessage = 'Illegal';
break;
case LoginForm :: WRONG_PLUGIN_PASS :
$errormessage = 'WrongPluginPass';
break;
case LoginForm :: NOT_EXISTS :
$errormessage = 'NotExists';
break;
case LoginForm :: WRONG_PASS :
$errormessage = 'WrongPass';
break;
case LoginForm :: EMPTY_PASS :
$errormessage = 'EmptyPass';
break;
default:
$errormessage = 'Unknown';
break;
}
if ($result != LoginForm::SUCCESS && $result != LoginForm::NEED_TOKEN ) {
error_log('Unexpected REMOTE_USER authentication failure. Login Error was:'.$errormessage);
}
$trycount++;
}
while ($tryagain);
return;
}
class Auth_remoteuser extends AuthPlugin {
function Auth_remoteuser() {
// Register our hook function. This hook will be executed on every page
// load. Its purpose is to automatically log the user in, if necessary.
if (isset($_SERVER['REMOTE_USER']) && strlen($_SERVER['REMOTE_USER'])) {
global $wgExtensionFunctions;
if (!isset($wgExtensionFunctions)) {
$wgExtensionFunctions = array();
}
else if (!is_array($wgExtensionFunctions)) {
$wgExtensionFunctions = array( $wgExtensionFunctions );
}
array_push($wgExtensionFunctions, 'Auth_remote_user_hook');
}
return;
}
/**
* Disallow password change.
*
* @return bool
*/
function allowPasswordChange() {
return false;
}
/**
* This should not be called because we do not allow password change. Always
* fail by returning false.
*
* @param $user User object.
* @param $password String: password.
* @return bool
* @public
*/
function setPassword($user, $password) {
return false;
}
/**
* We don't support this but we have to return true for preferences to save.
*
* @param $user User object.
* @return bool
* @public
*/
function updateExternalDB($user) {
return true;
}
/**
* We can't create external accounts so return false.
*
* @return bool
* @public
*/
function canCreateAccounts() {
return false;
}
/**
* We don't support adding users to whatever service provides REMOTE_USER, so
* fail by always returning false.
*
* @param User $user
* @param string $password
* @return bool
* @public
*/
function addUser($user, $password) {
return false;
}
/**
* Pretend all users exist. This is checked by authenticateUserData to
* determine if a user exists in our 'db'. By returning true we tell it that
* it can create a local wiki user automatically.
*
* @param $username String: username.
* @return bool
* @public
*/
function userExists($username) {
return true;
}
/**
* Check whether the given name matches REMOTE_USER.
* The name will be normalized to MediaWiki's requirements, so
* lower it and the REMOTE_USER before checking.
*
* @param $username String: username.
* @param $password String: user password.
* @return bool
* @public
*/
function authenticate($username, $password) {
global $_SERVER;
global $wgAuthRemoteuserAuthz;
global $wgAuthRemoteuserDomain;
if (isset($wgAuthRemoteuserAuthz) && $wgAuthRemoteuserAuthz != true)
return false;
if (!isset($_SERVER['REMOTE_USER'])) {
return false;
}
if (isset($wgAuthRemoteuserDomain) && strlen($wgAuthRemoteuserDomain)>0) {
$usertest = str_replace("$wgAuthRemoteuserDomain\\","",$_SERVER['REMOTE_USER']);
$usertest = str_replace("@$wgAuthRemoteuserDomain","",$usertest);
} else {
$usertest = $_SERVER['REMOTE_USER'];
}
return (strtolower($username) == strtolower($usertest));
}
/**
* Check to see if the specific domain is a valid domain.
*
* @param $domain String: authentication domain.
* @return bool
* @public
*/
function validDomain($domain) {
return true;
}
/**
* When a user logs in, optionally fill in preferences and such.
* For instance, you might pull the email address or real name from the
* external user database.
*
* The User object is passed by reference so it can be modified; don't
* forget the & on your function declaration.
*
* @param User $user
* @public
*/
function updateUser(&$user) {
global $_SERVER;
global $wgAuthRemoteuserName;
global $wgAuthRemoteuserMail;
global $wgAuthRemoteuserMailDomain;
global $wgAuthRemoteuserNotify;
global $wgAuthRemoteuserDomain;
global $wgAuthRemoteuserGroups; // = $_SERVER['AUTHENTICATE_MEMBEROF'];
global $wgAuthRemoteuserGroupRegex; // = '/CN=([^,]+),[^;]*;?/';
global $wgAuthRemoteuserOverwriteLocalGroups; // true to remove existing groups from wm database
if (isset($wgAuthRemoteuserName))
$user->setRealName($wgAuthRemoteuserName);
else
$user->setRealName('');
if (isset($wgAuthRemoteuserMail))
$user->setEmail($wgAuthRemoteuserMail);
elseif (isset($wgAuthRemoteuserMailDomain))
$user->setEmail($username . '@' . $wgAuthRemoteuserMailDomain);
else
$user->setEmail($username . "@example.com");
$user->mEmailAuthenticated = wfTimestampNow();
$user->setToken();
//turn on e-mail notifications
if (isset($wgAuthRemoteuserNotify) && $wgAuthRemoteuserNotify) {
$user->setOption('enotifwatchlistpages', 1);
$user->setOption('enotifusertalkpages', 1);
$user->setOption('enotifminoredits', 1);
$user->setOption('enotifrevealaddr', 1);
}
// See if we want groups
if (isset($wgAuthRemoteuserGroups) ) {
if (isset($wgAuthRemoteuserGroupRegex) ) {
// We've got a regex to split on
preg_match_all($wgAuthRemoteuserGroupRegex, $wgAuthRemoteuserGroups, $groupMatches);
if(count($groupMatches) == 2 && count($groupMatches[1]) > 0) {
$groupMatches = $groupMatches[1];
} else {
// Didn't find any groups at all. Should we log an error or just ignore?
$groupMatches = array();
}
} else {
/* No regex, so let's be a bit tricky. If the string contains semi-colon's, it's
* probably a list of DN's from LDAP, so we should split on that and give the full DN's.
* If not, let's assume it's just a comma separated list and run with it.
* And if it's not either of those, you'd better set a regex...
*/
if(FALSE === strstr($wgAuthRemoteuserGroups, ';')) {
// No semi's
$groupMatches = explode(',', $wgAuthRemoteuserGroups);
} else {
$groupMatches = explode(';', $wgAuthRemoteuserGroups);
}
}
// Remove existing groups that user is no longer in (if so configured.)
if ($wgAuthRemoteuserOverwriteLocalGroups) {
$curGroups = $user->getGroups();
foreach($curGroups as $group) {
if(FALSE === in_array($group, $groupMatches)) {
// No longer in this group, so remove it.
$user->removeGroup($group);
}
}
}
// Add in any new groups that aren't already present.
$curGroups = $user->getGroups();
foreach($groupMatches as $group) {
if(FALSE === in_array($group, $curGroups)) {
$user->addGroup($group);
}
}
}
$user->saveSettings();
return true;
}
/**
* Return true because the wiki should create a new local account
* automatically when asked to login a user who doesn't exist locally but
* does in the external auth database.
*
* @return bool
* @public
*/
function autoCreate() {
return true;
}
/**
* Return true to prevent logins that don't authenticate here from being
* checked against the local database's password fields.
*
* @return bool
* @public
*/
function strict() {
return false;
}
/**
* When creating a user account, optionally fill in preferences and such.
* For instance, you might pull the email address or real name from the
* external user database.
*
* @param $user User object.
* @public
*/
function initUser(&$user) {
global $_SERVER;
global $wgAuthRemoteuserDomain;
if (isset($wgAuthRemoteuserDomain) && strlen($wgAuthRemoteuserDomain)) {
$username = str_replace("$wgAuthRemoteuserDomain\\","",$_SERVER['REMOTE_USER']);
$username = str_replace("@$wgAuthRemoteuserDomain","",$username);
} else {
$username = $_SERVER['REMOTE_USER'];
}
$user->setName($this->getCanonicalName($username));
$user->saveSettings();
// Do we need to call this?
$this->updateUser($user);
}
/**
* Modify options in the login template. This shouldn't be very important
* because no one should really be bothering with the login page.
*
* @param $template UserLoginTemplate object.
* @public
*/
function modifyUITemplate(&$template) {
//disable the mail new password box
$template->set('useemail', false);
//disable 'remember me' box
$template->set('remember', false);
$template->set('create', false);
$template->set('domain', false);
$template->set('usedomain', false);
}
/**
* Normalize user names to the MediaWiki standard to prevent duplicate
* accounts.
*
* @param $username String: username.
* @return string
* @public
*/
function getCanonicalName($username) {
// lowercase the username
$username = strtolower($username);
// uppercase first letter to make MediaWiki happy
$username = ucfirst($username);
return $username;
}
}
?>
Wiki Admin
[edit]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)
- 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
[edit]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
if (isset($wgAuthRemoteuserName))
$user->setRealName($wgAuthRemoteuserName);
else
$user->setRealName('');
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
[edit]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
[edit]The LocalSettings.php require line is out of date and should be updated to this
require_once($IP . '/extensions/Auth_remoteuser/Auth_remoteuser.php');
--16:48, 6 April 2011 (UTC)
Unable to modify username
[edit]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:
[edit]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"]
: <nowiki>''</nowiki>;
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
[edit]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
[edit]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
[edit]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 str_replace rather than str_ireplace 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
[edit]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
[edit]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:
// Handle users without "Viewers" permission
$user = User::newFromName($usertest);
if ( ! in_array("Viewers", $user->getEffectiveGroups(true) ) ) {
// return false; // first thing I tried. figured returning false would reject authentication: did not work
// $wgOut->showPermissionsErrorPage("Error"); // tried to send the user to another page: did not work
Header("Location: invalid_user.php"); // this works, but it's ugly. Would like to keep it within the mediawiki app
}
else {
return ( strtolower( $username ) == strtolower( $usertest ) ); // same as original auth extension
}
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.
if ( !$user->isAnon() ) {
if ( $user->getName() == $wgAuth->getCanonicalName( $username ) ) {
return; // Correct user is already logged in.
} else {
$user->doLogout(); // Logout mismatched user.
}
}
Thanks in advance!
--Jamesmontalvo3 (talk) 17:25, 8 January 2013 (UTC)
Solved my own problem
[edit]I made an addition to Auth_remoteuser.php to allow me to:
- Only allow users of a certain group to view the wiki (it seems simply removing the view right from "users" does not work)
- Block most users despite being valid $_SERVER["REMOTE_USER"]
- Allow these non-viewers to view one page, in my case Project:Access_Denied
- Also allow them to view Project_Talk:Access_Denied
- With Extension:Talkright, this allows these non-viewers to edit the talk page, where they can request access (Admins are all watching this page)
- 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:
$wgAuthRemoteuserViewerGroup = "Viewers"; // set to false to allow all valid REMOTE_USER to view; set to group name to restrict viewing to particular group
$wgAuthRemoteuserDeniedPage = "Access_Denied"; // redirect non-viewers to this page (namespace below)
$wgAuthRemoteuserDeniedNS = NS_PROJECT; // redirect non-viewers to page in this namespace
// if set, only members of group $wgAuthRemoteuserViewerGroup will be allowed to view wiki
if ($wgAuthRemoteuserViewerGroup) {
// get the username from REMOTE_USER
$user = User::newFromName($username);
// determine talk namespace from namespace:title defined in
// $wgAuthRemoteuserDeniedNS and $wgAuthRemoteuserDeniedPage, respectively
$denied_talk_ns = Title::makeTitle( $wgAuthRemoteuserDeniedNS, $wgAuthRemoteuserDeniedPage )->getTalkPage()->getNamespace();
// Only users in group $wgAuthRemoteuserViewerGroup may enter the entirety of the wiki.
// Non-members of the group are able to view the "access denied" page (and its talk page),
// and will be redirected to "access denied" page if they attempt to view other pages.
if ( ! in_array($wgAuthRemoteuserViewerGroup, $user->getEffectiveGroups(true) ) &&
! ($title == Title::makeName( $wgAuthRemoteuserDeniedNS, $wgAuthRemoteuserDeniedPage)
|| $title == Title::makeName( $denied_talk_ns, $wgAuthRemoteuserDeniedPage) ) ) {
// redirect user to "access denied" page
$wgRequest->setVal("title", Title::makeName( $wgAuthRemoteuserDeniedNS, $wgAuthRemoteuserDeniedPage) );
}
}
Add the code above to the Auth_remote_user_hook() function, just below this block of code:
// Process the username if required
if ( !isset( $_SERVER['REMOTE_USER'] ) ) {
return;
}
if ( isset( $wgAuthRemoteuserDomain ) && strlen( $wgAuthRemoteuserDomain ) ) {
$username = str_ireplace( "$wgAuthRemoteuserDomain\\", "", $_SERVER['REMOTE_USER'] ); // remove "DOMAIN_NAME\" from the beginning
$username = str_ireplace( "@$wgAuthRemoteuserDomain", "", $username ); // remove @DOMAIN_NAME from the end
} else {
$username = $_SERVER['REMOTE_USER']; // if not domain name specified, use full REMOTE_USER
}
/**
* INSERT NEW CODE HERE
*/
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
[edit]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
[edit]Can't login :(
Alex
Conditional login
[edit]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
[edit]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?
[edit]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!
[edit]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
[edit]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 $wgPasswordPolicy from the DefaultSettings.php and to overwrite the MinimumPasswordLengthToLogin 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
[edit]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"
[edit]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 phab:T185391 -- Enst80 (talk) 17:44, 20 January 2018 (UTC)
Plugin not loading Group Permissions
[edit]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?
[edit]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:
if ( !is_string( $remoteUserName ) || empty( $remoteUserName ) ) {
$this->logger->warning(
"Can't login remote user '{remoteUserName}' automatically. " .
"Given remote user name is not of type string or empty.",
$metadata
);
continue;
}
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
$wgDebugLogFilevariable in yourLocalSettings.php, then have a look at the created logfile for lines starting with[session]. --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
[edit]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
$wgAuthRemoteuserUserName? 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"parsoid"user for the$wgAuthRemoteuserUserNamewhen$_SERVER[REMOTE_ADDR] == '127.0.0.1', @see new example #7 in the configuration details of$wgAuthRemoteuserUserName). -- 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" butalert(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 phab:T198928. --Enst80 (talk) 19:10, 20 July 2018 (UTC)
MediaWiki_Extensions_Auth_remoteuser_AuthRemoteuserSessionProvider_session expires on 1969-12-31T23:59:59.000Z
[edit]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
0for 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$wgCookieExpirationor$wgExtendedLoginCookieExpirationanywhere in your code (LocalSettings.phporinclude/DefaultSettings.phpmaybe)? -- Enst80 (talk) 22:51, 23 March 2018 (UTC)
Showing real name or e-mail instead of username?
[edit]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
mediawiki/includes/skins/SkinTemplate.phpand replace the$user->getName()with$user->getRealName(). For adjusting the special page "RecentChanges/PageHistory" have a look at the container class inmediawiki/includes/changes/RecentChange.php. --Enst80 (talk) 19:21, 20 July 2018 (UTC)
Problem with Parsoid
[edit]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
$wgAuthRemoteuserUserNamefor this specific use case --Enst80 (talk) 19:24, 20 July 2018 (UTC)
I do! You can tell apache not to request authentication for any locally-originated requests:
Require ip 127.0.0.1
Sessions dropping seems Auth_remoteuser related
[edit]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.
EditPage::importFormData: Failed token check; forcing preview 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
[edit]- 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:
- I would really appreciate some help in implementing the hack that adds:
if( !isset( $_COOKIE[session_name()] ) ) { User::SetupSession(); }in front of$wg->isLoggedIn()to/includes/user/user.php - However, the above hack seems to be outdated.
- nowhere in
user.phpcan I find$wg->isLoggedIn()"exactly" isLoggedIn()appears 7 times inuser.php
- Where should I add the
User::SetupSession();hack? - Should it be modified for MW 1.30 user.php? and if so, How?
- nowhere in
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:
- $wgMainCacheType = CACHE_ACCEL;
- $wgMemCachedServers = [];
Auth_remoteuser setting and then deleting session cookies for existing users
[edit]
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 phab:T198928 too. --Enst80 (talk) 19:27, 20 July 2018 (UTC)
page forms loose edits when session expires
[edit]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.
-Rich
- Just to be sure, can you use
2.1.0please 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$wgObjectCacheSessionExpiryto 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$wgObjectCacheSessionExpiryaccordingly; 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:
- click 'edit with form' on a form page.
- make some edits
- wait > 15 mintes
- click save
- observe that page redirects to remote immutable session provider with call-back to the referring page
- 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.
- observe user anger at lost data.
issue with PF and remote session re-validation?
[edit]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?
[edit]Has this been tested on MediaWiki 1.31 yet?
Multiple authentication
[edit]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,
The functionality you ask about has nothing to do with this extension. This extension uses whatever authentication the web server provides. So you would need to do your "dual authentication" at web server if using this extension.
MW 1.31 - logout token always failing
[edit]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:
.../wiki/index.php?title=Special:UserLogout&returnto=Main+Page&logoutToken=98dd9b13ed41f519038280cea9ce72a25d17fa4f%2B%5C
Our customized user URL is:
.../Shibboleth.sso/Logout?return=https://.../wiki/index.php?title=Special:UserLogout&returnto=Main_Page&logoutToken=8323ee9d33c6c9d52c5c240de2ae86cd5d17fc1f%2B%5C
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:
$personal_urls['SSOlogout'] = array(
'text' => 'Logout',
'href' => 'https://' . $_SERVER['HTTP_HOST'] . '/Shibboleth.sso/Logout?return=https://' . $_SERVER['HTTP_HOST'] . '/wiki/index.php?title=Special:UserLogout' . (((strpos($_SERVER['REQUEST_URI'], '/index.php/') !== false) && (strpos($_SERVER['REQUEST_URI'], 'Special:') === false)) ? ('%26returnto=' . urlencode(substr($_SERVER['REQUEST_URI'], strpos($_SERVER['REQUEST_URI'], '/index.php/') + 11))) : '') . '%26logoutToken=' . urlencode($wgUser->getEditToken('logoutToken'))
);
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'.