When reporting an error, please be sure to include version information for MediaWiki and all relevant extensions as well as configuration information. Also, please turn on debug logging as described at Manual:How to debug#Logging and include the relevant portions of the debug log.
Hi. New to the LDAP stack. I am rebuilding a wiki from stratch on recent components and I am running into this error when trying to log in. It looks like I am missing some basic component. I installed LDAPProvider, PluggableAuth, LDAPAuthentication2 and LDAPAuthorization. Any thoughts of what could be missing?
"[ZyGGDn92L1nyjPAY7pCs3gAAARU] /mediawiki/index.php?title=Special:PluggableAuthLogin Error: Call to undefined function ldap_connect() "
It looks like you may be missing php-ldap.
If you run ‘php -m | grep ldap’ what do you get?
I downloaded the version marked as compatible with MediaWiki 1.42.1 - PluggableAuth-REL1_42-b35addc.
However, I am receiving the message "Could not load authentication plugin". I am using SAML, so I also updated SimpleSAMLphp to the 1.42.1 version of that extension.
I had updated my PHP to 8.3.# since it is now compatible with this new version of MediaWiki. The error I got with that version of PHP indicated that there was deprecated code in PluggableAuth.
Deprecated: "Creation of dynamic property MediaWiki\Extension\PluggableAuth\BeginAuthenticationRequest::$pluggableauthlogin0 is deprecated in /var/www/html/includes/session/Session.php"
When I downgraded back to PHP 8.1#, the detailed error message disappeared, and I am now stuck with the vague message "Could not load authentication plugin".
Has anyone else experienced this. I am wondering if the current version of PluggableAuth is truly compatible with MediaWiki 1.42.1
I'm using this extension in production with MediaWiki 1.41 and PHP 8.1.
That said, I would look for more information from the debug log. Have you tried the steps in How to debug MediaWiki?
Thanks for the reply. I too am successfully running it in 1.41. The upgrade to 1.42 broke things. I didn't change any of the previous settings. I will check the debug logs in the morning to search for clues.
Any update on this? I've run into the same issue. Setup LDAP for my mediaiwki instance. Keep getting
Creation of dynamic property MediaWiki\Extension\PluggableAuth\BeginAuthenticationRequest::$password is deprecated in AuthenticationRequest.php on line 221
MediaWiki\Extension\PluggableAuth\BeginAuthenticationRequest::$pluggableauthlogin0 is deprecated in AuthenticationRequest.php on line 182
I tried the ShowUserGroups.php, and ShowUserInfo.php and it pulls up my user easily. But the CheckLogin.php shows FAILED eventhough my password is correct
I am experiencing the same original error. I have found that I also don't have REMOTE_User being set. I am upgrading from 1.41.1 to 1.42.1 using PluggableAuth and AuthRemoteUser. Here is the link to AuthRemoteUser comments. Extension talk:AuthRemoteUser - MediaWiki
after updating wiki we are seeing that for some users after login. we use 1.39.5 (f78a5fb) 06:10, October 10, 2023 . Note some users can login , others not. here is the full error: [c1f8b982694f124ffaf407db] /mediawiki/index.php?title=Special:UserLogin&returnto=Special%3ARecentChanges TypeError: preg_match(): Argument #2 ($subject) must be of type string, array given Backtrace: from /var/www/mediawiki/includes/parser/Sanitizer.php(1899)
What version of PluggableAuth and other related extensions are you using?
PluggableAuth 7.0.0 (211d5ba) 05:47, August 15, 2023
LDAPAuthentication2 2.0.1
the other Ldap extensions are 2.0.0
I'll work on getting debug set up.
Also, please turn on debug logging and include relevant portions of the log.
[LDAPProvider] Found user DN: 'uid=amy,ou=People,dc=test,dc=com'
[LDAPProvider] MediaWiki\Extension\LDAPProvider\Client::getSearchString: User DN is: 'uid=amy,ou=People,dc=test,dc=com'
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for localAutoCommit/0
[DBQuery] SqlBagOStuff::fetchBlobs [0s] localhost: SELECT keyname,value,exptime FROM `objectcache` WHERE keyname = 'fbcwiki:ldap-provider: user-info:amy:ou=People,dc=test,dc=com' AND (exptime >= '20231015232138')
[LDAPProvider] Ran LDAP search for '(uid=amy)' in 0.0020978450775146 seconds.
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for localAutoCommit/0
[DBQuery] Wikimedia\Rdbms\DatabaseMysqlBase::getServerId [0s] localhost: SELECT @@server_id AS id
[DBQuery] SqlBagOStuff::modifyTableSpecificBlobsForSet [0.003s] localhost: REPLACE INTO `objectcache` (keyname,value,exptime) VALUES ('fbcwiki: ldap-provider:user-info:amy:ou=People,dc=test,dc=com',.......
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for localAutoCommit/0
[LDAPAuthentication2] LDAP login succeeded.
[DBQuery] Wikimedia\Rdbms\DatabaseMysqlBase::open [0s] localhost: SET group_concat_max_len = 262144, `sql_mode` =
[DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: opened new connection for local/0
[DBPerformance] Expectation (masterConns <= 0) by MediaWiki::main not met (actual: 2): [connect to localhost (fbcwiki)]
henticate()
[DBQuery] Wikimedia\Rdbms\Database::beginIfImplied (User::load) [0s] localhost: BEGIN
[DBQuery] User::load [0s] localhost: SELECT actor_id,actor_user,actor_name FROM `actor` WHERE actor_name = 'Amy' LIMIT 1 [DBConnection] Wikimedia\Rdbms\LoadBalancer::getLocalConnection: reused a connection for local/0
Well,
TypeError: preg_match(): Argument #2 ($subject) must be of type string, array given Backtrace: from /var/www/mediawiki/includes/parser/Sanitizer.php(1899)
coming from
extensions/PluggableAuth/includes/PrimaryAuthenticationProvider.php(194): Sanitizer::validateEmail()
lets me think that either the LDAP server returns an odd value for what you have configured in emailattribute. Can you please check that value, e.g. by running extensions/LDAPProvider/maintenance/ShowUserInfo.php for the affected user?
Alternatively some handler of hook IsValidEmailAddr is messing up the e-mail address. But this seems unlikely.
sudo -u www-data php extensions/LDAPProvider/maintenance/ShowUserInfo.php --username amy --domain test.com
uid => amy mail => 0 => amy@test.com memberof => 0 => cn=nextcloud,ou=groups,dc=test,dc=com 1 => cn=UNIX Users,ou=groups,dc=test,dc=com givenname => Amy sn => O'test cn => Amy O'test dn => uid=amy,ou=People,dc=test,dc=com
Hello
Is there a way for me to further debug if some handler of hook IsValidEmailAddr is messing up the e-mail address ?
Well
mail => 0 => amy@test.com
is probably already the explanation.
It should more be
mail => amy@test.com
Unfortunately I can not tell why your LDAP server returns this value or why this only occurs for some users.
Can you check the same command with a user that hasn't got a problem?
well in our ldap a person can have more then one email address .
the ones which have more then one email address do have an issue logging in to wiki. for instance I can login and my returned from extensions/LDAPProvider/maintenance/ShowUserInfo.php is: rob@test
amy has 5 different email addresses with these as prefix :
0 => 1 =>
..
4 =>
we use openldap .
so the ones who can log in have just one email address, and ShowUserInfo.php returns something like
rob@test
without a 0 => prefix
I have created a patch for this on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/LDAPAuthentication2/+/966807
You can download the patched extension code via https://gerrit.wikimedia.org/r/changes/mediawiki%2Fextensions%2FLDAPAuthentication2~966807/revisions/2/archive?format=tgz
If you confirm this fixes the issue we can merge and release it.
I got this error after untaring the file into extensions/PluggableAuth
Fatal error: Uncaught Exception: It was attempted to load LDAPAuthentication2 twice, from /var/www/mediawiki/extensions/LDAPAuthentication2/extension.json and /var/www/mediawiki/extensions/PluggableAuth/extension.json. in /var/www/mediawiki/includes/registration/ExtensionProcessor.php:772 Stack trace: #0 /var/www/mediawiki/includes/registration/ExtensionProcessor.php(280): ExtensionProcessor->extractCredits() #1 /var/www/mediawiki/includes/registration/ExtensionRegistry.php(421): ExtensionProcessor->extractInfo() #2 /var/www/mediawiki/includes/registration/ExtensionRegistry.php(276): ExtensionRegistry->readFromQueue() #3 /var/www/mediawiki/includes/Setup.php(278): ExtensionRegistry->loadFromQueue() #4 /var/www/mediawiki/includes/WebStart.php(86): require_once('...') #5 /var/www/mediawiki/index.php(44): require('...') #6 {main} thrown in /var/www/mediawiki/includes/registration/ExtensionProcessor.php on line 772
here is a directory listing:
total 236
-rw-r--r-- 1 www-data www-data 135 Oct 18 18:34 CODE_OF_CONDUCT.md
-rw-r--r-- 1 www-data www-data 1212 Oct 18 18:34 composer.json
-rw-r--r-- 1 www-data www-data 1070 Jan 27 2023 COPYING
drwxr-xr-x 2 www-data www-data 4096 Aug 16 19:33 docs/
-rw-r--r-- 1 www-data www-data 1645 Oct 18 18:34 extension.json
-rw-r--r-- 1 www-data www-data 493 Oct 18 18:34 Gruntfile.js
drwxr-xr-x 2 www-data www-data 4096 Oct 18 18:34 i18n/
drwxr-xr-x 4 www-data www-data 4096 Aug 16 19:33 includes/
-rw-r--r-- 1 www-data www-data 241 Oct 18 18:34 package.json
-rw-r--r-- 1 www-data www-data 191732 Oct 18 18:34 package-lock.json
-rw-r--r-- 1 www-data www-data 265 Oct 18 18:34 README.mediawiki
drwxr-xr-x 2 www-data www-data 4096 Oct 18 18:34 src/
drwxr-xr-x 4 www-data www-data 4096 Jan 27 2023 tests/
The patch is an update to LDAPAuthentication2, not PluggableAuth. You should be untarring it into extensions/LDAPAuthentication2, not extensions/PluggableAuth.
Howdy. Is there an example of what the addOnlyGroups array should look like?
I have SimpleSAMLPHP setup and working with azure AD. I also have sso working on mediawiki using PluggableAuth and the SimpleSAMLPHP plugin. However, I cannot get group mappings to work.
I have my mediawiki debug logging turned on and can see the Azure group identity/claims/role guids being returned to, however, Pluggable auth keeps removing my user from groups they should be in, in the debug logs:
[PluggableAuth] Removing 'username@domain.com' from group 'sysop'
I'm wondering if I should adding the addOnlyGroups array, but I can't figure out the syntax.
$wgPluggableAuth_Config['SSO Login'] = [
'plugin' => 'SimpleSAMLphp',
'data' => [
'authSourceId' => 'default-sp',
'emailAttribute' => 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress',
'realNameAttribute' => 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name',
'usernameAttribute' => 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name',
'userinfoProviders' => [
'username' => 'rawusername',
],
],
'groupsyncs' => [
[
'type' => 'mapped',
'map' => [
'sysop' => [ 'groups' => 'azure group ID guids' ],
'user' => [ 'groups' => 'azure group ID guids' ]
],
'addOnlyGroups' => [ 'sysop', 'user' ],
]
]
];
Im having issues with an OpenIDConnect setup. After signing it (doesn't matter if its first time) I am getting redirected to a page with 'Fatal error authenticating user.', at that time the site shows me as 'Anonymous'. If I then open the homepage of the wiki on Edge it shows me as signed in with the correct name, etc. and everything works as expected.
This doesnt happen if the existing cookie/token is reused and im not prompted to login.
On Chrome or Firefox it still does not show me as logged in after going to the homepage but I do a session cookie.
PluggableAuth debug log:
Getting PluggableAuth instance
Plugin name: OpenIDConnect
In execute()
Getting PluggableAuth instance
Plugin name: OpenIDConnect
In execute()
Getting PluggableAuth instance
Could not get authentication plugin instance.
ERROR: return to URL is null or empty
I don't know if this will help you in this instance, but I too was having the same issue. I'm going to explain what I went through in case it helps in the right direction or helps others in future.
At first I was trying to use OpenID Connect to authorise with my self hosted Authentik. I couldn't even get redirected to the authentik log in screen, just got a 'Fatal error authenticating user.'
Today I tried using MS Entra ID, same issue.
I found in /var/log/messages that SELinux was preventing the http request. So I ran setsebool -P httpd_can_network_connect 1
Now when I try to login I actually get to the MS login screen, and then get redirected back after successful auth. I can see the successful auths in the Entra portal too.
However, I still got 'Fatal error authenticating user.'
I disabled SELinux as a test to see if maybe it was blocking more things, but same issue remains, re-enabled SELinux.
At this point I was out of ideas but found SELinux was also preventing me from writing a debug.log using $wgDebugLogFile = "$IP/debug.log";
Sorted that out and could then grep the log for PluggableAuth|OpenIDConnect and I see the same logline as OP.
[PluggableAuth] ERROR: return to URL is null or empty
but slightly earlier in the log I also saw my Layer8 issue.
[OpenIDConnect] Jumbojett\OpenIDConnectClientException: bla: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app 'my-app-id-redacted'.
I was indeed using the wrong value here. Once I entered the right value, everything is working as expected.
I have had LDAP configured and working for many years, using older versions of the plugins where the config was in the LocalSettings.php file. I'm finding this is now broken with the current MediaWiki update and am trying to update the extensions for PluggableAuth and the LDAPStack. I actually tried this once before and gave up, but that appears no longer to be an option.
I am working from the manual and have created the JSON file, which I believe is correct. At this point I am getting an error when loading the site that indicates the following:
[42210a3c72f542b606307239] / TypeError: PluggableAuthHooks::doBeforeInitialize(): Argument #6 ($mw) must be of type MediaWiki, MediaWiki\Actions\ActionEntryPoint given, called in c:\pathto\mediawiki\includes\HookContainer\HookContainer.php on line 159
Backtrace:
from c:\pathto\mediawiki\extensions\PluggableAuth\includes\PluggableAuthHooks.php(113)
#0 c:\pathto\mediawiki\includes\HookContainer\HookContainer.php(159): PluggableAuthHooks::doBeforeInitialize(MediaWiki\Title\Title, NULL, MediaWiki\Output\OutputPage, MediaWiki\User\User, MediaWiki\Request\WebRequest, MediaWiki\Actions\ActionEntryPoint)
#1 c:\pathto\mediawiki\includes\HookContainer\HookRunner.php(937): MediaWiki\HookContainer\HookContainer->run(string, array)
#2 c:\pathto\mediawiki\includes\actions\ActionEntryPoint.php(384): MediaWiki\HookContainer\HookRunner->onBeforeInitialize(MediaWiki\Title\Title, NULL, MediaWiki\Output\OutputPage, MediaWiki\User\User, MediaWiki\Request\WebRequest, MediaWiki\Actions\ActionEntryPoint)
#3 c:\pathto\mediawiki\includes\actions\ActionEntryPoint.php(145): MediaWiki\Actions\ActionEntryPoint->performRequest()
#4 c:\pathto\mediawiki\includes\MediaWikiEntryPoint.php(199): MediaWiki\Actions\ActionEntryPoint->execute()
#5 c:\pathto\mediawiki\index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#6 {main}
As you can infer, I am on Windows and IIS. Happy to provide any other info about the config if needed. Would genuinely appreciate any help.
Hello,
In my case I got this same error message & stack just after upgrade MediaWiki from 1.41.2 to 1.42.1 (there are few minutes).
I downloaded latest version of PluggableAuth: Extension:PluggableAuth for my current MediaWiki version (1.42).
Remove previous extension install dir. : $MW_HOME/extensions/PluggableAuth
And extract archive in this extension directory: $MW_HOME/extensions/
And now it is work again perfectly.
I hope this solution can you help you.
Regards,
Thank you very much for replying. I am also updating to 1.42.1. I was downloading updates from MediaWiki plugin page and I was able to determine that there was a different version on the linked page for direct downloads. After downloading from there and getting version 7.1.0, the error went away and I was able to login.
I have multi domian for login ,but when I use $wgPluggableAuth_Config like this, I have two login button with the name as "Login1" and "Login2" for differrent domain login.
I want to show only one login button, to login with different domain which contain local domain.
$wgPluggableAuth_Config['Login1'] = [
'plugin' => 'LDAPAuthentication2',
'data' => [
'domain' => 'LDAP0'
]
];
$wgPluggableAuth_Config['Login2'] = [
'plugin' => 'LDAPAuthentication2',
'data' => [
'domain' => 'LDAP1'
],
];
| LDAPAuthentication2 | 2.0.9 (1ca14ce) | GPL-2.0 |
| LDAPProvider | 2.0.7 (5f0b37f) | GPL-2.0+ |
| LoginNotify | 0.1 | MIT |
| PluggableAuth | 7.1.0 (4111a57) |
Hey
I created a new extension, using PluggableAuth. It aims to reproduce Extension:Auth remoteuser in its first incarnation: have one page in your wiki that checks for REMOTE_USER and uses it to authenticate. Unfortunately, I have only basic knowledge of remote authentication and mediawiki's authentication process. I basically just copied from here and there, so maybe someone with a bit more knowledge can have a look at the source code and check, if there is no major foo bar in it.</nowiki>
What the extension does:
PluggableAuthLogin.phpMediaWiki\Extension\PluggableAuth\PluggableAuth checks, if it is colled from the extension's special pageheader())$_SERVER['REMOTE_USER'] and uses the username of the principal for authenticationHelp and feedback is appreciated. Thanks in advance.
MediaWiki 1.41.0 (62e7aef)
OpenID Connect 7.0.2 (c515880)
PluggableAuth 7.0.0 (2d86d50)
PHP 8.2.17 (apache2handler)
ICU 72.1
PostgreSQL 16.0
I'm unclear on the correct way to reference field in the access_token from the OIDC payload and assign them to the default roles in mediaWiki using groupsyncs. I have the following defined in LocalSettings.php. below that I have the access_token example pulled from the jwt. Logging in works great. But auto-assigning users that have thefieldwithrole to a group doesn't seem to be working.
Any insight into what I might be doing wrong?
$wgPluggableAuth_Config[] = [
'plugin' => 'OpenIDConnect',
'data' => [
.......
],
'groupsyncs' => [
[
'type' => 'mapped',
'map' => [
'users' => [ 'thefieldwithrole' => 'roleA' ],
'sysop' => [ 'thefieldwithrole' => 'roleB' ]
]
]
]
];
Example Access_Token pulled from jwt payload:
{
"thefieldwithrole" : "roleA",
"aud" : "omitted",
"authorization_details": [],
"client_id" : "theclientid",
"client_key" : "theclientkey",
"Email" : "someemailaddress",
"exp" : 1234567890
"first_name" : "first",
"iss" : "omitted",
"jti" : "xf8i7vW",
"last_name" : "last",
"login" : "12345678",
"Organization" : "theorg",
"samaccountname" : "12345678",
"scope" : "openid profile",
"sub" : "12345678",
"subject" : "12345678",
"uid" : "12345678",
"userid" : "12345678",
"userId" : "12345678",
}
hello, i'm in the process of trying to figure this out. i'm using azure ad and openid connect.
have you had any success figuring things out?
Apologies for the delay... I haven't been focused on this much this week. But, no... I haven't quite figured it out (yet). It "seems" like the code isn't seeing the "thefieldwithrole" from the access_token of the OIDC token payload.
Without any other guidance to go by, my current thinking is to try putting my authZ info into the authorization_details[] section of the payload in accordance with the intent of the RFC... maybe the extension author is expecting to find the information there... unsure. If that doesn't work, may slog through the extension code to see if I can figure it out.... just getting to the point where I can't delay the project much longer and may try something else.
https://datatracker.ietf.org/doc/html/rfc9396
"This specification introduces a new parameter authorization_details that allows clients to specify their fine-grained authorization requirements using the expressiveness of JSON [RFC8259] data structures.¶"
your response is greatly appreciated.
i have managed to get passed authentication. but i'm finding it difficult for my log in to pull group memberships from the local azure ad/entra. and likewise, if i find anything, i'll share it.
thanks
OK, i was able to get groupsync working between azure ad and wiki
i think something to consider is how azure ad is configured as well. on top of the claim for user info when the wiki app is registered in the azure portal, a groups claim needs to be added.
a rough instruction is :
Azure Active Directory > App registrations > the wiki app > Token configuration(might be under Manage) > is there a group claim?
if not, click Add optional claim > ID for id tokens > Group > ...hopefully you can follow from there. i think its better to use group id than samaccountname
then when configuring PluggableAuth_Confiig...
'groupsyncs' => [
[
'type' => 'mapped',
'map' => [
'information_technology' => ['groups' => 'azure ad group id'] ]
]
]
]
'groups' is needed, though i cannot remember why. I found this explanation using ChatGPT ", the groups claim in a token can contain the IDs of the Azure AD groups to which the user belongs"
hopefully that helps some? good luck
I tried following your solution, but it seems to still not be working for me.
"The only difference is I am using the SimpleSAMLphp plugin: The following does not work. Any suggestions on what I am doing wrong?
$wgPluggableAuth_Config["Log in without Password (SSO)"] = [
"plugin" => "SimpleSAMLphp",
"data" => [
"authSourceId" => "default-sp",
"usernameAttribute" => "email",
"realNameAttribute" => "displayname",
"emailAttribute" => "email",
"groupAttributeName" => "....schemas.microsoft.com/ws/2008/06/identity/claims/role" ],
'groupsyncs' => [
[
'type' => 'mapped',
'map' => [
'sysops' => [ 'groups' => 'Admin' ],
'bureaucrat' => [ 'groups' => 'User_draft_edit' ],
'suppress' => [ 'groups' => 'User_draft_read' ]
]
]
]
];"
Hi,
I'm using the PluggableAuth extension in combination with the OpenIDConnect extension. When a user logs in, the groups returned by the provider (Entra in my case) will re-sync the user's groups in MediaWiki via the "syncall" configuration option for PluggableAuth.
I was wondering, is there a way to trigger a group sync besides having the user log in? Some of our users don't login in that frequently, so the groups listed in MediaWiki for the user become out-of-sync with the provider groups. This isn't necessarily an authorization problem, since a user who lost or gained a group that would revoke or permit access should have that access updated upon the next login. However, the groups listed in MediaWiki make it appear as though someone might have access who shouldn't (or vice versa).
Thanks!
Dan