Previous discussion was archived at Extension talk:Auth remoteuser/Archive on 16 June 2020.
The latest "released" version 2.1.1 is not yet compatible to MediaWiki 1.39. One needs either to use REL1_39 or master branch. Using master may be dangerous with future updates.
Unfortunately the extension description does not state an official "Compatibility policy".
Could the maintainer of this extension maybe update the "Compatibility policy" and/or release a version 3.0.0 that is compatible to MediaWiki 1.39?
Thanks in advance!
looks like the new MediaWiki is throwing warning in the PHP errors log every page load
PHP Deprecated: Use of PersonalUrls hook (used in hook-PersonalUrls-closure) was deprecated in MediaWiki 1.39. [Called from MediaWiki\HookContainer\HookContainer::run in C:\inetpub\wwwroot\wiki\includes\HookContainer\HookContainer.php at line 137] in C:\inetpub\wwwroot\wiki\includes\debug\MWDebug.php on line 381
You should disable php deprecation notices on production websites. Otherwise, this may need to be a bugreport.
Hmm, I'm getting this exact warning too, but not a problem once I turned off the notices.
MW 1.39: Continuous Deprecation notices on Auth_remoteuser.
When Auth_remoteuser extension is active, the following depreciation notices will appear:
Deprecated: Use of PersonalUrls hook was deprecated in MediaWiki 1.39. [Called from Hooks::register in /var/www/html/includes/Hooks.php at line 55] in /var/www/html/includes/debug/MWDebug.php on line 381
Deprecated: Hook PersonalUrls was deprecated in MediaWiki 1.39 but is registered in /var/www/html/extensions/PluggableAuth/extension.json in /var/www/html/includes/debug/MWDebug.php on line 381
Deprecated: Use of PersonalUrls hook (used in hook-PersonalUrls-closure) was deprecated in MediaWiki 1.39. [Called from MediaWiki\HookContainer\HookContainer::run in /var/www/html/includes/HookContainer/HookContainer.php at line 137] in /var/www/html/includes/debug/MWDebug.php on line 381
This is regardless of debugging statements specified in LocalSettings. All extensions are at the 1.39 release. Auth_remoteuser, LDAPAuthentication2, LDAPGroups, LDAPUserInfo, PluggableAuth.
I have the same problem, any solution provided?
Also, somehow if Auth_remoteuser always trying to create a new user even though the User provided by $_SERVER[REMOTE_USER] exists.
MediaWiki User
I have the same problem i version 1.38.4 is there any new solution for this problem?
Heelo,
after migration to Mediwaki 1.38.0 and upgradin extension too, I run into this message :
MWException: CAS update failed on user_touched. The version of the user to be saved is older than the current version.
Backtrace:
from ../includes/user/User.php(2813)
- 0 ../includes/libs/rdbms/database/Database.php(4428): User->{closure}()
- 1 ../includes/libs/rdbms/database/DBConnRef.php(69): Wikimedia\Rdbms\Database->doAtomicSection()
- 2 ../includes/libs/rdbms/database/DBConnRef.php(645): Wikimedia\Rdbms\DBConnRef->__call()
- 3 ../includes/user/User.php(2825): Wikimedia\Rdbms\DBConnRef->doAtomicSection()
- 4 ../extensions/Auth_remoteuser/src/UserNameSessionProvider.php(846): User->saveSettings()
- 5 ../extensions/Auth_remoteuser/src/UserNameSessionProvider.php(630): MediaWiki\Extension\Auth_remoteuser\UserNameSessionProvider->setUserPrefs()
- 6 ../includes/session/SessionManager.php(843): MediaWiki\Extension\Auth_remoteuser\UserNameSessionProvider->refreshSessionInfo()
- 7 ../includes/session/SessionManager.php(544): MediaWiki\Session\SessionManager->loadSessionInfoFromStore()
- 8 ../includes/session/SessionManager.php(247): MediaWiki\Session\SessionManager->getSessionInfoForRequest()
- 9 ../includes/WebRequest.php(837): MediaWiki\Session\SessionManager->getSessionForRequest()
- 10 ../includes/session/SessionManager.php(168): WebRequest->getSession()
- 11 ../includes/Setup.php(861): MediaWiki\Session\SessionManager::getGlobalSession()
- 12 ../includes/WebStart.php(93): require_once(string)
- 13 ../index.php(44): require(string)
Any idea ?
Thanks
You may look at the user_touched field of the user table for that particular user, if it contains a "sane" value. It should be a number-like, "YYYYMMDDHHmmss" (year month day hour minute second), in the past, not null nor empty
For example: 20000101000000
Thanks for your answer, the value stored is 20220603142256 that seems good to me.
I managed to get the extension working again (my configuration below):
// Load extension wfLoadExtension( 'Auth_remoteuser' ); // If account creation by anonymous users is forbidden, then allow // it to be created automatically. $wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['*']['autocreateaccount'] = true; // Remote source for user name $wgAuthRemoteuserUserName = $login; // Apply once on user creation $wgAuthRemoteuserUserPrefs = [ 'realname' => $name, 'language' => 'fr', 'email' => $email ]; // Apply on each request $wgAuthRemoteuserUserPrefsForced = [ 'realname' => $undefined, 'email' => $undefined ];
in $wgAuthRemoteuserUserPrefsForced I used $undefined which is an undefined var. If I put everything that exist (such as a real var, a string or empty string) I trigger the error. The only way to make it work is to provide a variable that doesn't exist ... but it work as expected in the user profile ...
Yeah it works if I stop using `$wgAuthRemoteuserUserPrefsForced`, but that's not really a solution because I need to use it. It also only happens with one user, and the user table looks totally ordinary.
Any idea what triggers the warning and how to avoid it?
I found out that it only happens if `$wgAuthRemoteuserUserPrefsForced` contains something different than the database, eg. if it has to change something. Runnung in PHP 7.4 right now, maybe this is the reason? Would be suprised if yes…
OMG! I believe I've found the solution! After allowing sysop to change userrights it works:
`$wgGroupPermissions['sysop']['userrights'] = true`
I don't really understand why it doesn't have this right the first place, but…
That solved another problem I had, but not the one we face here. No idea what's happening. I will try to find another solution for updating the user realname and email in the Wiki DB though. :-/
There's a "bureaucrat" user group that has the userrights right by default. sysops usually can do administrative tasks but not change other users' groups, unless you choose to give them that right.
I ended up commenting out in includes/user/User.php the lines 2600-2602 and now everything works like a charm:
throw new MWException( "CAS update failed on user_touched. ".
"The version of the user to be saved is older than the current version."
);
I don't really understand why, but $dbw->affectedRows() returns 0 even the changes get written to the database this way. It sounds silly to remove the error throwing, but this way the extension works as intended.
For the past 11 years, our wiki has authorized access to users in the DB of my forum software. This has worked over at least two LTS MW versions using two different flavors of authentication extensions. However, in my attempt to upgrade my wiki to current 1.39.1 LTS, I've discovered that my working extension, Extension:IPBAuthLogin relies on a deprecated method, getCanonicalName(). It's a really simple extension that works very nicely for our needs. Closed wiki with access only to forum members by matching normalized user names supplied by the forum DB. Wiki user management is super simple.
So if I am unable to sort that out, I think Auth remoteuser will work if I can get some direction on how to configure for this use case ... which seems a lot simpler than the other methods where more configuration instruction is provided. I posted more detailed information about that problem on the help desk to see if I can get any general advice.
But this extension should be my ace-in-the-hole if someone would be so kind as to give me some nudges.
Thank you!
I am running MediaWiki 1.38.2 on Debian 5.10.120-1:
MediaWiki 1.38.2
PHP 7.4.30 (fpm-fcgi)
MariaDB 10.6.8-MariaDB
ICU 67.1
With the following extensions:
VisualEditor 0.1.2
CategoryTree –
ParserFunctions 1.6.0
TreeAndMenu 4.2.5, 2021-10-31
Auth_remoteuser 2.1.1 (7155b49)
CollapsibleVector 0.1.11
LDAPAuthentication 2 1.0.3
LDAPProvider 1.0.5
PluggableAuth 5.7
After much trial-and-errorI got LDAP Authentication to work.
Now I would like to get auto-login to work.
My apache runs as "daemon".
When I turn on Auth_remoteuser with:
wfLoadExtension( 'Auth_remoteuser' );
$wgAuthRemoteuserUserName = getenv( 'USER' );
I do get automatically logged on but the user is "daemon" which is the user Apache is running I am guessing (which is a bit weird in and of itself because "daemon" is not present in LDAP...)
How can I tell it to use the requester's windows user?
Best regards,
Andrei
getenv( 'USER' ) is the user running the webserver.
Look at the details of $wgAuthRemoteuserUserName for configuration examples.
Note that your apache should be configured to authenticate against Windows, and this probably requires installing an NTLM apache module and a working samba client configured on the system). Once that works (for example, requiring a valid user and displaying an error page if the user is not valid/provided/detected) you should know at which server variable is that user stored, and use it to set $wgAuthRemoteuserUserName
Auth_remoteuser extension is deleting properly formatted usernames
when executing the "UserNameSessionProviderFilterUserName" hook
even when the $wgAuthRemoteuserUserNameReplaceFilter setting is null.
How can I bypass the hook execution if I have already determined the username
format entry is correct?
Currently using MW 1.31
Hello,
I'm trying to integrate this extension into FreedomBox, which is a a piece of software that offers a one-click installaation for MediaWiki. For starter, the following apache config works well:
<Location /mediawiki>
Include includes/freedombox-single-sign-on.conf
<IfModule mod_auth_pubtkt.c>
TKTAuthToken "wiki" "admin"
</IfModule>
</Location>
However, this way the whole wiki becomes private, and you have to log in to read the pages. My goal is to authenticate only when the user visits the login page. If I set the Location to be <Location /mediawiki/Special:UserLogin>, it does authenticate, but when I jump on the main page, the user logs out immediately.
I tried setting
$wgArticlePath and $wgCookieDomain
with no success, though I'm not entirely sure about the correctness of these two.
Is it possible to auhtenticate only on the login page, and have the user not log out when navigating elsewhere?
this is solved. It was an issue in an extension that was using this extension.
Is this extension supposed to work in MW 1.35?
We are running into problems after upgrading an installation from MW 1.31 to 1.35. Authentication is still working, but errors are shown in the browser console.
We seem to run into this issue: https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager/Updating_tips#Exception_%22Sessions_are_supposed_to_be_disabled_for_this_entry_point%22
load.php?lang=de&modules=startup&only=scripts&raw=1&skin=chameleon:40 [e8bfac0498b9f61221749bd4] /load.php?lang=de&modules=startup&only=scripts&raw=1&skin=chameleon BadMethodCallException from line 848 of includes/session/SessionManager.php: Sessions are disabled for this entry point Backtrace:
(anonymous) @ load.php?lang=de&modules=startup&only=scripts&raw=1&skin=chameleon:40
A question about Number 5 i the extension page:
// This is not advised, because it will evaluate every visitor
// to the same wiki user 'Everybody'
$wgAuthRemoteuserUserName = "Everybody";
I tried to use this form and insert a substring called $username read from a cookie containing the username instead of "Everybody",
$wgAuthRemoteuserUserName = $username;
but it seems to evaluate to nothing and the user is not logged in.
When I echo the string read from the cookie it looks ok.
If i write the the same cookie value as a string, and run the function on it, the function to read the username and log in works fine. I tried a lot of other string operations on the value as a string, and it still works, but when I try to use the substring from the cookie it will not login. What is wrong?
How do you get that substring? Maybe there's some error in your code and the value doesn't get assigned at all
Hi, I'm upgrading our organizational wiki from MW 1.31 to MW 1.35, which means I'm also upgrading from PHP 7.2 to 7.4. We're upgrading from Auth remoteuser v1 to v2. Under MW 1.31 and Auth remoteuser v.1 worked perfectly and users were able to automatically log in using their certs. Following the upgrade, I'm not able to log in. The application tells me to log in, even though I know my certs are being read. I could use some advice from anyone who's used this extension with PKI certs. I'm sure I'm overlooking something obvious, but I've been looking at this problem for too long. Thanks in advance for the help.