About this board


Previous discussion was archived at User talk:Cindy.cicalese/Archive 1 on 2017-03-17.

MediaWiki Ver 1.32: PluggableAuth and SimpleSAMLphp compatible version

Frizzow (talkcontribs)

My mediawiki ver is 1.32 and we would like to use PluggableAuth and SimpleSAMLphp with azure AD.

Currently, We have no plan to upgrade the ver in anytime soon due to internal decision. If we would like to stay on 1.32 ver more longer and would like to use the mentioned extension for SSO ex: PluggableAuth and SimpleSAMLphp. Can i download the latest extension version from the drop down menu like 1.36(latest stable MediaWiki) or 1.35 since the status is LTS? if it's not possible, should i download the same extension ver from git? I tried to find the extension ver for 1.32 from git but i can’t find it because i’m not very familiar with it.

Appreciate your helps

Cindy.cicalese (talkcontribs)

You should be able to use the latest stable versions of both extensions with MediaWiki 1.32 at this point. I believe that both maintain backward compatibility at this point to at least 1.31.

Reply to "MediaWiki Ver 1.32: PluggableAuth and SimpleSAMLphp compatible version"
X-Savitar (talkcontribs)
The Technical Barnstar
For all the amazing work you do on CommentStreams. Thank you! X-Savitar (talk) 17:21, 12 August 2021 (UTC)
Cindy.cicalese (talkcontribs)

Awwww, thank you!!

X-Savitar (talkcontribs)

You're welcome! 🎉

Reply to "A barnstar for you!"

Relative image links for SemanticRating extension?

Theowl84 (talkcontribs)


today I installed the SemanticRating extension. It is very helpful for our task and easier to install than any Template. However, I immediately stumbled across a problem with the image links for the stars. Our wiki can be reached from inside and outside the local network but the SemanticRating.php $imagepath is composed as an absolute URL (which leads to unreachable images for internal accesses or external accesses). The simple fix for this problem was to remove the $GLOBALS['wgServer'] part of $imagepath so the images ended up being relative URLs like any other image reference on the wiki.

So my question is why SemanticRating has absolute image paths in the first place? As far as I'm aware of, all other intra-wiki links or image-refs use relative URLs starting with $wgScriptPath, too. I don't know if I'm missing a problem here, but if not I would suggest removing the $wgServer part of the image URLs.

Thanks, Matthias

Cindy.cicalese (talkcontribs)

There is no good reason that it uses an absolute path. Please feel free to submit a patch in gerrit to change the path.

Thanks, Cindy

Reply to "Relative image links for SemanticRating extension?"

AD authentication for Mediawiki

2A01:9820:2:7:0:0:3E68:2F02 (talkcontribs)


you are listed on the Extension:LDAPAuthentication2 Page as Author. I want to ask is there a solution for not using a bind account to authenticate against active directory? This was possible with the old extension (Extension:LDAP Authentication). I have no good feelings adding a user an password to json file and have this inside an repo for automatic deployments. Why is this needed? LDAP Selfauth should work also fine.

Cindy.cicalese (talkcontribs)

@Osnard implemented this functionality and perhaps could respond here.

2A01:9820:2:7:0:0:3E68:2F02 (talkcontribs)

@Cindy.cicalese thx for the fast response. I have send an email to @Osnard yesterday. I'm also found it very annoying to have an json File with credentials in the webserver root. This makes security much more complex.

I also found it very strange that the most of the extensions are not able to install via composer. This makes automatic deployments with dependency tracking much harder as it should be.

MarkAHershberger (talkcontribs)
I also found it very strange that the most of the extensions are not able to install via composer.
I think I have deployed this with composer. See mediawiki/ldap-authentication-2 and mediawiki/ldap-provider (though, there is a missing dependency that I should fix).
I know @Osnard deploys these with composer, but Hallo Welt! uses their own repository.
I'm also found it very annoying to have an json File with credentials in the webserver root
You certainly do not have to do that. You can put the .json file wherever you want and point $LDAPProviderDomainConfigs to it.
2A01:9820:2:4:F2D5:BFFF:FE93:E234 (talkcontribs)

@MarkAHershberger @Cindy.cicalese thx for your feedback, I hope you had a nice Easter.

@MarkAHershberger: The composer stuff was not only for this module We have a list of extension we need to use, only a few are available via composer. It would be really god for the future if it where possible to do the complete installation and updates via composer. This would make CI pipelines much better.

@MarkAHershberger: For the json file, I still see not the need why we need a bind user for the extension. Other tools can do it without.

As I wrote we try to deploy our installation as docker images. And hard coded credentials are a mess. I muss now parse two different

config file formats ( Localsettings.php and json) via docker-entrypoint script to put the right credentials in via environment variables.

@Cindy.cicalese @MarkAHershberger @Osnard From my view it would be better to have the stuff in the Localsettings.php and even better don't need a bind user, or make it optional. I have no example for php but for example netbox (open source dcim tool) works without bind user.

Osnard (talkcontribs)
Cindy.cicalese (talkcontribs)
2A01:9820:2:4:F2D5:BFFF:FE93:E234 (talkcontribs)

@Cindy.cicalese: for me as user this would be a great improvement.

@Osnard: I send you an email some day's before about the ldap question above, why do the extension need a bind user? Have you seen it?

2A01:9820:2:7:0:0:3E68:2F02 (talkcontribs)

@Osnard @Cindy.cicalese I still got no feedback about the initial question why it needs a bind user?

Osnard (talkcontribs)
2A01:9820:2:4:F2D5:BFFF:FE93:E234 (talkcontribs)

@Osnard I think a self bind would make it much more secure. So you don't need any ldap user with global read access. And you have no credentials on your servers. I will take a look into the source code. I'm no php programmer but if it is easy I will try to send an patch.

Reply to "AD authentication for Mediawiki" (talkcontribs)

Hi Cindy,

We want to use OpenID connect with last MediaWiki release - 1.35.1. It requires PHP 7.3.19+ and when we try to authenticate we get an error: php deprecated: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead

This function is using here (912 line):

public function requestUserInfo($attribute = null) {

        $user_info_endpoint = $this->getProviderConfigValue("userinfo_endpoint");

        $schema = 'openid';

        $user_info_endpoint .= "?schema=" . $schema;

        //The accessToken has to be send in the Authorization header, so we create a new array with only this header.

        $headers = array("Authorization: Bearer {$this->accessToken}");

        $user_json = json_decode($this->fetchURL($user_info_endpoint,null,$headers));

        $this->userInfo = $user_json;

        if($attribute === null) {

            return $this->userInfo;

        } else if (array_key_exists($attribute, $this->userInfo)) {

            return $this->userInfo->$attribute;

        } else {

            return null;



I tried to fix this using property_exists() function, but seems like it don't working well. Could you please help with it?


Stanislav Babaryka


Cindy.cicalese (talkcontribs)

I believe that you are using an old version of the OpenID Connect extension. The extension makes use of an OpenID Connect library. The code you refer to is in that library. It is fixed in verion 0.9.0 of the library. The most recent version of the extension uses version 0.9.1 of the library. You can see this by looking for 'jumbojett/openid-connect-php' in the composer.json file of the extension. I suggest that you get the latest version of the extension, version 5.4, which includes this update. (talkcontribs)

Hi again!

Yes, it worked well with new version, thanks!

But we have new issue now - when new user created during login it haven't email in it profile. Only attribute that new user receives from azure AD is realname.

LocalSettings part with plugins config:

wfLoadExtension( 'PluggableAuth' );

$wgPluggableAuth_EnableLocalLogin = true;

$wgPluggableAuth_ButtonLabelMessage = "Office 365 Login";

wfLoadExtension( 'OpenIDConnect' );

$wgOpenIDConnect_Config['h ttps://sts.windows.net/***************************/'] = [

        'clientID' => '*****************************',

        'clientsecret' => '****************************'


$wgOpenIDConnect_UseRealNameAsUserName = true;

If I define username as email, it will have "User 1" name.

Maybe I missing something or you can suggest what I need to check.

Thanks in advance!



Cindy.cicalese (talkcontribs)

I understand the bit about the email not getting set, but I'm not sure if you are saying you also have a problem using the real name as the username? It makes sense that it would use 'User 1' if you are using the email address for the name, but no email address and no preferred username is provided. (talkcontribs)

Problem is with retrieving email from provider. Real name as username works correctly, but when i try to use email as username i'm getting "User 1". Also there is no email in "email" field in account properties. From Azure side all is ok, all necessary API permissions for Azure App are granted.

Cindy.cicalese (talkcontribs)

OK, I see. Unfortunately, I'm not familiar with configuring Azure to get it to return the email address. Unless it provides it to the extension, there's nothing the extension can do to get that information. There are other folks using Azure successfully, so it seems there must be a way to configure it to return that information if it exists on the Azure end.

Cindy.cicalese (talkcontribs)

You could try adding the scope parameter to your config:

$wgOpenIDConnect_Config['h ttps://sts.windows.net/***************************/'] = [

        'clientID' => '*****************************',

        'clientsecret' => '****************************'

      'scope' => [ 'openid', 'profile', 'email' ]

    ]; (talkcontribs)

Thanks! With adding Scope and some code editing it works!

Thank you for helping

Cindy.cicalese (talkcontribs)

Great! I have updated the documentation to include the scope parameter in all of the examples.

Reply to "OpenID Connect PHP 7.4"

OpenID Connect with Gitlab (self-hosted)

2 (talkcontribs)

Hi Cindy,

I want to share my configuration to use OpenID Connect with a Gitlab (self-hosted).


  • Login to Gitlab Admin Area
  • Applications -> New Application
    • Name: MediaWiki
    • Redirect URI: <<https wiki server>>/wiki/Special:PluggableAuthLogin
    • Trusted: yes
    • Confidential: yes
    • Scopes: openid, profile, email
  • Submit
  • Copy Application ID and Secret to LocalSettings.php

MediaWiki Configuration

In LocalSettings.php

# Extension:OpenID Connect
wfLoadExtension( 'PluggableAuth' );
# set to false to deactivate local logins
$wgPluggableAuth_EnableLocalLogin = true; #= false;

wfLoadExtension( 'OpenIDConnect' );
$wgOpenIDConnect_Config['<<https gitlab server>>'] = [
    'clientID' => '...', # Insert Gitlab Application ID here!
    'clientsecret' => '...', # Insert Gitlab Secret here!
    # docs.gitlab.com/ee/integration/openid_connect_provider.html
    # Alternative 'nickname'
    # Alternative 'name'
    'preferred_username' => 'nickname'
$wgPluggableAuth_ButtonLabelMessage = 'Login with your Gitlab Account';
Cindy.cicalese (talkcontribs)

Thank you very much for contributing this! Please feel free to update Extension:OpenID Connect with these instructions!


Reply to "OpenID Connect with Gitlab (self-hosted)"
Estin Giç Giç (talkcontribs)

Hello Cindy,

I found you on recent changes, can you hide my IP Topic:Vk2wxxb5bxbovovq here, please.

Have a nice day!

Silkwood (talkcontribs)

Hi Cindy,
do you know why if the page title (the node) contains symbols (e.g. a single quote) VIKi puts the corresponding HTML number (that is: &#39;) instead?

For example if, in my wiki, I have the node Rickett's Hornpipe and the VIKI graph will render it as Rickett&#39;s Hornpipe

Is there a way to solve this misbehaviour?

Thank you.

Cindy.cicalese (talkcontribs)

Unfortunately, there is no longer an active maintainer for Extension:VIKI.

Reply to "Extension:VIKI graph"
Billinghurst (talkcontribs)

Hi. Not sure which account you are more actively watching this or WMF. This one is definitely more active.

I noted some observations to JDF the other day, and he said that maybe they should be flagged to you. Thanks if you can take a peek.

Reply to "Pinging"

Extension:LDAP Authentication

Aschroet (talkcontribs)

Hi Cindy, do you know if there is any progress/update on the mentioned plugin? Can we at least expect it? I guess that many users wait for it.

Cindy.cicalese (talkcontribs)

Good question! Let me look into that and get back to you.


2003:72:6D2A:9E00:C089:626A:E54F:136D (talkcontribs)

Hello toegether!

I know how to solve one of the issues at least and I have posted the way to the solution here: Topic:Tlz6fw5aasbglko8!

Would be great, if someone could integrate this fix!

Osnard (talkcontribs)
Vbhttb (talkcontribs)

I wish to move mediawiki 1.26 in 1.31 but I need Ldap (company rule)

I'm trying to install LDAP Autentication2 with LDAP Provider and PlugableAuth in 1.31

Result is a [038e54b61e1b8be5ce73ffcb] 2019-01-26 20:51:05: Fatal exception of type "Error"

Are you able to suggest help?

Cindy.cicalese (talkcontribs)
Reply to "Extension:LDAP Authentication"