Project:Support desk

Welcome to the MediaWiki Support desk, where you can ask MediaWiki questions!

(Read this message in a different language)

See also

Other places to ask for help:

• Chat rooms
  • Wikimedia Chat (Mattermost)
  • MediaWiki unofficial (Discord)
  • Outreachy chat (Zulip)
  • Hackathon chat - (Telegram @wmhack group)
• Email groups
• StackOverflow (third-party)
• Unofficial MWUsers forum (third-party)

Before you post

• Check the basic How does MediaWiki work? guide.
• Check the FAQ and Errors and symptoms .
• If your question is about a specific feature, check the relevant technical manual , end-user help or extension page and consider asking on its talk page .
• For issues about the mediawiki.org website, report to Current issues instead.
• For trying out wiki editing, use the Sandbox instead.

Post a new question

1. To help us answer your questions, please indicate which versions you are using, as found on your wiki's Special:Version page:
   • MediaWiki version
   • PHP version
   • Database type and version
2. Please include the web address (URL) to your wiki if possible. It's often easier for us to identify the source of the problem if we can see the error directly.
3. To start a new thread, click "Start a new topic".

Hi, I wanted to change my tiny personal wiki (that ONLY I have access to). I wanted to remove the Login / Reset password based on Username, so folks couldn't gork me for fun.

I found this page: https://www.mediawiki.org/wiki/Manual:$wgPasswordResetRoutes

And as a result I added this to my LocalSettings.php:

$wgPasswordResetRoutes

[

'username' => false,

'email' => true,

]

But immediately got this error:

Parse error: syntax error, unexpected '=>' (T_DOUBLE_ARROW), expecting ']' in [redacted]/LocalSettings.php on line 222

I'm a novice to MediaWiki operation. I've tried lots of variations on the above, INCLUDING COMMENTING IT ALL OUT, and it STILL won't let me in.

I get the impression that the error lodged something in the wiki's database (or whatever) that's now effectively broken it.

I have MediaWiki v. 1.35.1

Help please?? I can't get into my wiki at all now.

Edit P.S.: Can some one tell me the right way to phrase $wgPasswordResetRoutes so it doesn't gork my wiki?

Why would there be a www.mediawiki.org/wiki/Manual page whose instructions immediately and permanently crash a wiki?

Thanks!

You have a syntaxerror in your LocalSettings.php

In the directory, you can use php -l LocalSettings.php to check for syntaxerrors on your settings file. Make sure you don't have syntax errors.

Did you read what I said? Even commenting it out or removing it - restoring back to what it was before I touched it - still gives the exact same error. Yikes it's scary!

Check you've saved the file after editing it :-)

Thanks, btdt, laugh... but yes. I even triple-checked by downloading the updated file (where I commented out the new code that breaks my wiki) to my PC. I confirmed that it is no longer there.

And my wiki is still completely broken. The entire site or trying to access any page on it gives that error. Even though the offending command is completely gone from LocalSettings.php now.

How can this be?

Maybe type it in again but put the equals sign between the variable name and the [ ] - that missing equals is likely what caused the error.

Maybe type some obvious nonsense earlier in the file to see whether it causes an error :-) Maybe somehow you have two MediaWiki installations and are editing the wrong one.

Also a semicolon after the ]

Maybe you've not successfully commented it out at all. If you use an editor like Notepad++ it'll make it easy to see using different text colours. Though you did say that completely removing it didn't stop the same error appearing...

Thanks for trying to help but gosh, isn't it clear that it's not my LocalSettings.php any more? At this point I've completely commented it out, I've completely stripped it out, I even replaced LS.php with a backup copy from February. And I STILL get the same error about a double-arrow at line 222, which doesn't even exist in that file any more. And No, there isn't a second wiki on my site. The only change I did was to the LS.php, which I've since reversed.

Can we cut to the chase please -

How can an LS.php entirely break a wiki's php such that it doesn't even matter what the LS.php is any more? How can it be fixed? Please god don't say re-install everything from top to bottom. I have no idea how to do that.

This is so saddening. It's already so much work and hunting and pecking to try to improve even the smallest thing, like that Password Reset idea. And then I apparently kill my wiki by following simple instructions on a MediaWiki page.

I always blame caching when I can't understand something. Maybe somehow you're getting an old version? Maybe try on a different device that's never seen the error message.

It's located on a SiteGround server. Were you thinking it was on my PC or something? I've tried hitting Control-F5 (I'm using Win10) which would rightly upload an old image I re-uploaded. But it doesn't help here. FWIW using your idea, I tried logging on with my phone (which I haven't done in months). It too gives the error.

News flash: I am finding that if I access my wiki through specific pages, it does work just fine. E.g. [site]/wiki/index.php?title=[a specific page]

Ten out of 12 of these work just fine, if addressed directly, or via links already on my pages. And I can edit them just fine. (That's 10 out of 12 of a recent project page and subpages. I haven't checked my dozens of other older pages.)

But [site]/wiki/index.php?title=Main_Page (my home page) still gives the error, and the page I had been working on at the time I edited my LS.php also gives the error, plus one other I haven't touched in a week.

Hmm.

Another update: I called my host provider and did what they call a complete backup of everything; the backup was from 12 hours ago (which is fine).

It did not fix the problem!

So I have to wonder if it could be some kind of cache issue. But where? On the host server? On my PC? I've completely closed an opened my browser several times. Also used ^F5. No joy. I don't know how the host service caches stuff, or if it even does.

Note, for server side frontend caching (e.g. varnish, cloudflare, cloudfront, etc) try bypassing the caching by ending &x=1234 at the end of the url.

This type of caching is usually not on by default (and mw has to be configured special for it to work properly) so that may or may not do anything.

That worked! All the pages that previously gave the error (same as in OP) load okay, with &x=1234 appended.

But if I try to load them yet again without &x=1234, they show the error again. Edit - if I keep reloading them, some are showing okay now without the x=1234.

Could you please say a little more about what level (where) the caches are? Yet I don't know how to permanently flush caches with the error-causing page. Are they just on my host (SiteGround), or spread out all over (third party site caching for ISPs)?

Anyway thanks! - at least now I'm seeing that all is not lost.

And many thanks @Johnathan3 again for trying to hold my hand. Isn't it so weird that the erroneous page would persist as the cached one?? This probably explains how at first, many stayed broke no matter what I did. Then a bunch got better, though I effectively didn't do anything, at least at the point in time they got better (I had fixed LS.php much earlier). And now almost all of them seem okay (fingers crossed).

Ok, lets take a step back.

What is the current error message you are getting? Is it the same as the original one?

What is the current contents of your LocalSettings.php? Can you put the entire thing (redacting any passwords or secret key variables) on to a pastebin so we can see it?

If there are pages that work, and you can edit those pages (not just view) and have the edits show up, then it is some sort of caching issue and not LocalSettings.php

If you can, linking to your wiki might also be helpful.

I have some svg icons that I want to add to certain sites. How can I tell MediaWiki that the svgs should not be converted to pngs?

I tried $wgSVGConverter = false; but that shows no picture at all, but only a download link for the svg.

Of course I can use something like <img src="My.svg" /> but I'd like to go with [[File:My.svg]].

When do SVGs get converted to PNG? Please provide context and steps to reproduce.

Look at the image (pencil) on https://secret-wiki.de/wiki/Datei:Editieren.svg for example. It's name is 17px-Editieren.svg.png instead of Editieren.svg.

You may be looking for Extension:NativeSvgHandler

Thanks. If there's no other way I will try that. What is the reason why MediaWiki transforms svg to png by default? Is it because svg was not well supported by browsers in the beginning? Meanwhile 98.5 % of online users can display svg correctly (according to https://caniuse.com/svg).

As of Nov 2, 2021, it's now up tp 99.61% support according to https://caniuse.com/svg. It's time to at least make this a configuration option.

never underestimate the power of status quo.

There is some concern that for certain images, transforming is a better choice if the svg is really big. There is also some concern that people are used to the current rendering engine and existing images might break if we used browsers. Both those seem mild to me though.

Hi, the current fonts on Sindhi Wikipedia are not good enough, so I want to change the fonts on Sindhi Wikipedia for entire site, how can I do that.?

Welcome to the support desk for the MediaWiki software. For Wikimedia sites, please see meta:Requesting_wiki_configuration_changes. Also make sure to explain what exactly the problem is, on which URLs, which text, with which browser(s) on which operating systems. Thanks.

Thanks

You can change them by editing MediaWiki,:common.css if you are an admin

suppose if I ask local interface admin to do this font-family: Georgia, "Calibri", Times, "sans-serif"; be changed to font-family: Georgia, "MB Sindhi Sahat ", MB Sindhi Sahat , "MB Sindhi Sahat "; ???

No, see phab:T294773.

I am admin but I can't edit it, bcz this right is given to local Interface admin, this right should also be given to general admin bcz sometimes local admin are not active on small wikis, in there absence if this right may be given to admins also then they can fix some issues.

No, see "Requests" on meta:Interface administrators what to do instead.

When I change the font used on my wiki to Times New Roman, it seems tiny in comparison with Arial... what is the best way to increase the font size slightly throughout the whole wiki? Thanks.

Topic:Rlh02nwq7plg9i93

Thanks. I'd read that and it didn't help me, either with Vector or the main skin I use, Foreground. I'll try again though.

P.S. I've now asked the question on the Foreground skin talk page at Topic:Win59vfzm0kkpukv.

I compromised and used Georgia in the end. It has serifs, which I want, but is about the same size as Arial so I won't need to adjust any CSS.

https://developer.mozilla.org/en-US/docs/Web/CSS/font-size

If you added something like that and it didnt take affect it could be something else in the skin overriding it. Browser dev tools can be helpful in that situation.

Thanks. I'd tried that but wasn't able easily to increase the font consistently across the website. I probably could have done with stacks of lines of CSS but it didn't seem worth it.

The odd things was that when I just changed the font everything worked out at 16px (as before with Arial), but when I compared it with a plain 1990s website with Times New Roman also at 16px the text on the wiki was somehow smaller. To make it a bit bigger I was having to use font-size em/rem values to increase the px, but it was hard to change it consistently across the different elements of the website.

can i use different fonts?

"can i use different fonts?" Yes, you could just use font-family for the relevant things, in MediaWiki:Common.css.

Ok, thanks.

When trying to edit any page using the PortableInfoboxes extension, I get this error:

Call to undefined method ObjectCache::getMainWANInstance()

It would seem that this means the extension is accessing something that is no longer supported, and that many others have had this issue with no helpful responses. However, I have been able to see that this extension works for some people... how do I fix this? I have not been able to find any way to deal with this issue, which prevents me from making any edits to the wiki.

What is Extension:PortableInfoboxes? Please provide a link and see "Post a new question" in the sidebar. Thanks.

I guess this is probably about Extension:PortableInfobox.

OP: what version of MediaWiki are you using? You say that many others have had this issue with no helpful responses — could you link to those discussions?

I think it should be using \MediaWiki\MediaWikiServices::getInstance()->getMainWANObjectCache() instead

Have you tried filing a bug at https://github.com/lkucharczyk/mediawiki-PortableInfobox/issues i dont see anyone else complaining about this issue

I've been following the instructions (posted with the LDAP Stack extensions) on how to setup the LDAP authentication with some difficulty. I'm currently at a loss, and have tried for a few hours to get this right. Any help would be really appreciated!

I think all of the extensions are installed and setup properly. I've made sure to chown -R apache:apache for all of the installed extensions.

But when I run the update.php system, I receive this message:

[administrator@ubsa-web wiki]$ php maintenance/update.php

Found invalid JSON in file: /var/www/html/wiki/ldap.json

[38e932627974f1bcc47e1156] [no req]   MWException from line 42 of /var/www/html/wiki/extensions/LDAPProvider/src/DomainConfigProvider/LocalJSONFile.php:

Could not access configuration file '/etc/mediawiki/ldapprovider.json'!

Please set up a domain configuration file for the LDAPProvider extension.

Backtrace:

#0 /var/www/html/wiki/extensions/LDAPProvider/src/DomainConfigProvider/LocalJSONFile.php(73): MediaWiki\Extension\LDAPProvider\DomainConfigProvider\LocalJSONFile->__construct(string)

#1 [internal function]: MediaWiki\Extension\LDAPProvider\DomainConfigProvider\LocalJSONFile::newInstance(MediaWiki\Extension\LDAPProvider\Config)

#2 /var/www/html/wiki/extensions/LDAPProvider/src/DomainConfigFactory.php(106): call_user_func_array(string, array)

#3 /var/www/html/wiki/extensions/LDAPAuthentication2/src/Setup.php(12): MediaWiki\Extension\LDAPProvider\DomainConfigFactory::getInstance()

#4 /var/www/html/wiki/includes/Setup.php(906): MediaWiki\Extension\LDAPAuthentication2\Setup::init()

#5 /var/www/html/wiki/maintenance/doMaintenance.php(83): require_once(string)

#6 /var/www/html/wiki/maintenance/update.php(277): require_once(string)

#7 {main}

I'm running on CentOS7 apache php7.2. I can connect to our LDAP system using this web server for other packages like OwnCloud.

When I go to the login screen, it gives me the option of local or the domain authentication.

But when trying to login using LDAP/AD, I get the following:

[XsP8CcWSnGSXTwj7yKISUgAABM4] 2020-05-19 15:32:25: Fatal exception of type MWException

ldap.json file:

{

  "itorg.ad.buffalo.edu": {

     "connection": {

        "server": "itorg.ad.buffalo.edu",

        "port": "636",

        "user": "CN=BLANKED-FOR-THIS-POST,OU=Groups,OU=UBSA,OU=StudentAssociation,OU=ITORGS,DC=itorg,DC=ad,D$

        "pass": "BLANKED-FOR-THIS-POST",

        "enctype": "clear",

        "options": {

                "LDAP_OPT_DEREF": 1

        },

        "basedn": "DC=itorg,DC=ad,DC=buffalo,DC=edu",

        "userbasedn": "DC=itorg,DC=ad,DC=buffalo,DC=edu",

        "groupbasedn": "DC=itorg,DC=ad,DC=buffalo,DC=edu",

        "searchattribute": "samaccountname",

        "usernameattribute": "samaccountname",

        "realnameattribute": "cn",

        "emailattribute": "mail",

        "grouprequest": "MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\UserMemberOf::f$

        "presearchusernamemodifiers": [ "spacestounderscores", "lowercase" ]

     },

     "userinfo": [],

     "authorization": [],

     "groupsync": {

        "mapping": {

           "sysop": "CN=UBSA_Pro_Staff,DC=itorg,DC=ad,DC=buffalo,DC=edu"

        }

     }

   }

}

LDAP Setting in LocalSettings.php:

//LDAP Authentication Config

$wgMinimalPasswordLength = 6;

$wgPasswordPolicy['policies']['sysop']['MinimalPasswordLength'] = 6;

$wgPasswordPolicy['policies']['Administrators']['MinimalPasswordLength'] = 6;

$wgPasswordPolicy['policies']['interface-admin']['MinimalPasswordLength'] = 6;

$wgPasswordPolicy['policies']['bureaucrat']['MinimalPasswordLength'] = 6;

wfLoadExtension( 'LDAPProvider' );

wfLoadExtension( 'PluggableAuth' );

wfLoadExtension( 'LDAPAuthentication2' );

$LDAPAuthentication2AllowLocalLogin = true;

// Create Wiki-Group 'engineering' from default user group

$wgGroupPermissions['UBSA_Pro_Staff'] = $wgGroupPermissions['sysop'];

// Private Wiki. External LDAP login. Default NS requires login.

$wgEmailConfirmToEdit = false;

$wgGroupPermissions['*']['edit'] = false;

$wgGroupPermissions['*']['read'] = false;

$wgGroupPermissions['*']['createaccount'] = false;

$wgGroupPermissions['sysop']['createaccount'] = true;

$wgGroupPermissions['*']['autocreateaccount'] = true;

$wgBlockDisablesLogin = true;

// Load LDAP Config from JSON

$ldapJsonFile = "$IP/ldap.json";

$ldapConfig = false;

if (is_file($ldapJsonFile) && is_dir("$IP/extensions/LDAPProvider")) {

  $testJson = @json_decode(file_get_contents($ldapJsonFile),true);

  if (is_array($testJson)) {

    $ldapConfig = true;

  } else {

    error_log("Found invalid JSON in file: $IP/ldap.json");

  }

}

$wikiRequestSafe  = true;

// Activate Extension

if ( $ldapConfig ) {

  wfLoadExtension( 'PluggableAuth' );

  wfLoadExtension( 'LDAPProvider' );

  wfLoadExtension( 'LDAPAuthentication2' );

  wfLoadExtension( 'LDAPAuthorization' );

  wfLoadExtension( 'LDAPUserInfo' );

  wfLoadExtension( 'LDAPGroups' );

  $LDAPProviderDomainConfigs = $ldapJsonFile;

  $wgPluggableAuth_ButtonLabel = "Log In";

  if ($wikiRequestSafe) { $LDAPAuthentication2AllowLocalLogin = true; }

}

Looks like "$IP/ldap.json" is not accessible then running the CLI script "maintenance/update.php".

Strange thing is, that it obviously is accessible when using the web interface. Otherwise the login form would not display the Domain name.

To get a better error message than "Fatal exception of type MWException", please add the following lines to your "LocalSettings.php" file:

$wgShowExceptionDetails = true;
$wgShowSQLErrors = true;
$wgShowDBErrorBacktrace = true;

Thanks for the reply!!! This is what I got after trying to login:

[XsQUTLZuY8gaqJ-QEWcbjQAABoQ] /index.php?title=Special:PluggableAuthLogin MWException from line 168 of /var/www/html/wiki/extensions/LDAPProvider/src/Client.php: Could not bind to LDAP: (-1) Can't contact LDAP server

Backtrace:

#0 /var/www/html/wiki/extensions/LDAPProvider/src/Client.php(91): MediaWiki\Extension\LDAPProvider\Client->establishBinding()

#1 /var/www/html/wiki/extensions/LDAPProvider/src/Client.php(328): MediaWiki\Extension\LDAPProvider\Client->init()

#2 /var/www/html/wiki/extensions/LDAPAuthentication2/src/PluggableAuth.php(77): MediaWiki\Extension\LDAPProvider\Client->canBindAs(string, string)

#3 /var/www/html/wiki/extensions/PluggableAuth/includes/PluggableAuthLogin.php(31): MediaWiki\Extension\LDAPAuthentication2\PluggableAuth->authenticate(NULL, string, NULL, NULL, NULL)

#4 /var/www/html/wiki/includes/specialpage/SpecialPage.php(575): PluggableAuthLogin->execute(NULL)

#5 /var/www/html/wiki/includes/specialpage/SpecialPageFactory.php(611): SpecialPage->run(NULL)

#6 /var/www/html/wiki/includes/MediaWiki.php(296): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)

#7 /var/www/html/wiki/includes/MediaWiki.php(900): MediaWiki->performRequest()

#8 /var/www/html/wiki/includes/MediaWiki.php(527): MediaWiki->main()

#9 /var/www/html/wiki/index.php(44): MediaWiki->run()

#10 {main}

Seems like its not talking to the LDAP server? But would this be connected to the Update.php issue? I see in the instructions, until I can run update.php successfully some stuff needed for LDAP wont be written to the SQL DB.

Should I try running update.php as apache using sudo? Currently running it as the local user account.

So I ran update.php using sudo -u apache and it completed without error. However, I'm still getting the error I posted just above this.

Ok, so the connection issue was the encryption type. I'm using SSL connections, and it was set to "clear". Now its set to SSL, and the error is

[XsRZdLZuY8gaqJ-QEWcfHQAABpQ] /index.php?title=Special:PluggableAuthLogin MWException from line 168 of /var/www/html/wiki/extensions/LDAPProvider/src/Client.php: Could not bind to LDAP: (49) Invalid credentials

I know the credentials I'm using are correct. I'm using the same username/PW for LDAP connections on Joomla, OwnCloud, and a few other systems. I even double checked and logged into Apache Directory Studio using the same credentials.

I also double checked, php-ldap is installed and enabled.

I'll keep working on this, but any ideas/help wold be greatly appreciated.

Got it all figured out. It was OU related. Thanks for the help @Osnard, your nudge is what got me moving again.

Good to hear! Have fun with your wiki :)

Hi all,

I am a newbie in mediawiki. I do not have any knowledge about webserver (because i am a embedded programmer). But now i need to deploy a website which saved all document of our project.

Recently, I run a local mediawiki successfull. And now, i want to integrate LDAP feature for another colleagues who can authen and author through existing data from our company data.

I setup my LDAP as the following steps, please help me to check this:

1. Download LDAPAuthentication2 and extract to \extensions folder. Add wfLoadExtension( 'LDAPAuthentication2' ); to LocalSettings.php.
2. Download LDAPProvider and extract to \extensions folder. Add wfLoadExtension( 'LDAPProvider' ); to LocalSettings.php.
3. Download PluggableAuth and extract to \extensions folder. Add wfLoadExtension( 'PluggableAuth' ); to LocalSettings.php.
4. Add more to LocalSettings.php:

$wgPluggableAuth_EnableAutoLogin = false;

$wgPluggableAuth_EnableLocalLogin = false;

$wgPluggableAuth_EnableLocalProperties = false;

$wgPluggableAuth_ExtraLoginFields = [];

$wgShowExceptionDetails = true;

$wgShowSQLErrors = true;

$wgShowDBErrorBacktrace = true;

5. That's it. I do not add anything more.

6. I run: php maintenance\update.php and get the following error:

C:\xampp\htdocs\w\maintenance>php update.php

[17efe3e1264caa9b02bf0038] [no req]   MWException from line 42 of C:\xampp\htdocs\w\extensions\LDAPProvider\src\DomainConfigProvider\LocalJSONFile.php:

Could not access configuration file '/etc/mediawiki/ldapprovider.json'!

Please set up a domain configuration file for the LDAPProvider extension.

Backtrace:

#0 C:\xampp\htdocs\w\extensions\LDAPProvider\src\DomainConfigProvider\LocalJSONFile.php(73): MediaWiki\Extension\LDAPProvider\DomainConfigProvider\LocalJSONFile->__construct(string)

#1 [internal function]: MediaWiki\Extension\LDAPProvider\DomainConfigProvider\LocalJSONFile::newInstance(MediaWiki\Extension\LDAPProvider\Config)

#2 C:\xampp\htdocs\w\extensions\LDAPProvider\src\DomainConfigFactory.php(106): call_user_func_array(string, array)

#3 C:\xampp\htdocs\w\extensions\LDAPAuthentication2\src\Setup.php(12): MediaWiki\Extension\LDAPProvider\DomainConfigFactory::getInstance()

#4 C:\xampp\htdocs\w\includes\Setup.php(906): MediaWiki\Extension\LDAPAuthentication2\Setup::init()

#5 C:\xampp\htdocs\w\maintenance\doMaintenance.php(83): require_once(string)

#6 C:\xampp\htdocs\w\maintenance\update.php(277): require_once(string)

#7 {main}

7. And i reload the main page and get the same errors message.

Please help me to install LDAP completely (as detailed as possible). Please please and please.

Thank you so much.

Did you create the ldap.json file containing the LDAP connection information?

No I don't. Do you have guideline for create the ldap.json @Rosenblitt?

Thank you.

Have a look at LDAP_hub/Migration_from_extension_LDAPAuthentication#Example_1. Not JSON, but PHP. Should also work.

What would need to be added to the ldapprovider.json file for automatic creation of a wiki account if all that is required would be a valid AD user?

Nothing. Extension:PluggableAuth, which is the base of Extension:LDAPAuthentication2, will automatically create an user on login, as long as the * group has the autocreateaccount permission assigned.

Not sure if this should go to a new topic or not, but I have been beating my head against a wall for a while.

I have a mediawiki (v 1.31) page, and want to auto-create accounts based on a successful LDAP search.

Having tested both CheckLogin.php and ShowUserInfo.php on my own credentials I get successful results.

How can I get the username information from a registration page into the $wgAuthRemoteuserUserName variable?

Here's my relevant configuration information:

### LDAP Extension Loads:

wfLoadExtension ( 'PluggableAuth' );

wfLoadExtension ( 'LDAPProvider' );

wfLoadExtension ( 'LDAPAuthentication2' );

wfLoadExtension ( 'LDAPAuthorization' );

wfLoadExtension ( 'LDAPGroups' );

wfLoadExtension ( 'LDAPUserInfo' );

wfLoadExtension ( 'Auth_remoteuser' );

### LDAPProvider / LDAPAuthentication2 Config:

$LDAPProviderDomainConfigs = "/etc/mediawiki/ldapprovider.json";

$LDAPProviderDomainConfigProvider = "\\MediaWiki\\Extension\\LDAPProvider\\DomainConfigProvider\\LocalJSONFile::newInstance";

$LDAPProviderCacheType            = "CACHE_ANYTHING" ;

$LDAPProviderCacheTime            = 500 ;

$wgGroupPermissions['*']['createaccount'] = true;

$wgGroupPermissions['*']['autocreateaccount'] = true;

$LDAPAuthentication2UsernameNormalizer = 'strtolower';

$LDAPAuthentication2AllowLocalLogin = true;

$wgAuthRemoteuserAllowUserSwitch = true;

$wgPluggableAuth_EnableLocalLogin = false;

LDAP JSON file (/etc/mediawiki/ldapprovider.json):

#------------------------------------------------------------------------#

{

        "DOMAIN": {

                "connection": {

                        "server": "<REDACTED>",

                        "user": "<REDACTED>",

                        "port": "3269",

                        "pass": "<REDACTED>",

                        "enctype": "ssl",

                        "options": {

                                "LDAP_OPT_DEREF": 1

                        },

                        "basedn": "<REDACTED>",

                        "groupbasedn": "<REDACTED>",

                        "userbasedn": "<REDACTED>",

                        "searchattribute": "samaccountname",

                        "searchstring": "domain\\USER-NAME",

                        "usernameattribute": "samaccountname",

                        "realnameattribute": "cn",

                        "emailattribute": "mail",

                        "domain-backslash-username": "MediaWiki\\Extension\\LDAPAuthorization\\AutoAuth\\RemoteUserStringParser\\DomainBackslashUsername::factory",

                        "grouprequest": "MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\UserMemberOf::factory",

                        "presearchusernamemodifiers": [ "spacestounderscores", "lowercase" ]

                },

         "userinfo": [],

         "authorization": {

                     "rules": {

                           "groups": {

                                "required": [ "CN=Domain Users,CN=Users,<REDACTED>" ]

                           }

                     }

          }

        }

}

#------------------------------------------------------------------------#

Since I have run successful tests on the ShowUserInfo.php and CheckLogin.php, I believe that there is nothing wrong with

my ldapprovider.json file, and the trouble is with how $wgAuthRemoteuserUserName should be assigned. The method I have

currently always returns null, apparently because $_SERVER[ 'REMOTE_USER' ] does not appear to be set.

$wgAuthRemoteuserUserName = function() {

        $user = '';

        if( isset( $_SERVER[ 'REMOTE_USER' ] ) ) {

                $user = strtolower( $_SERVER[ 'REMOTE_USER' ] );

        }

        return $user;

};

Extension:LDAPAuthorization will transform a remote user name into one that is actually required by the other extensions. E.g. assume that $_SERVER['REMOTE_USER'] === 'DOMAIN\\JaneDoe', you can use

$LDAPAuthorizationAutoAuthRemoteUserStringParser = "domain-backslash-username";

to have Extension:LDAPAuthorization extract "DOMAIN" (careful: case sensitive!) and load the proper domain config from LDAPProvider. It will also rewrite the username to "Janedoe" implicitly, so you don't need to modify $wgAuthRemoteuserUserName on your own. If you have $_SERVER['REMOTE_USER'] === 'JaneDoe@DOMAIN', you can use

$LDAPAuthorizationAutoAuthRemoteUserStringParser = "username-at-domain";

instead.

Be aware that for using Extension:Auth_remoteuser you need to have a network based authentication like Kerberos or NTLM be set up in the webserver. This is a completely different authentication method than using the Special:Userlogin form in the wiki.

Thanks for that information. As a follow-up question, I saw that there is a ConfirmAccount extension for the mediawiki software. Has anybody updated this for implementation with the current LDAP Stack extensions?

I don't think so. Unfortunately I do not know Extension:ConfirmAccount well enough to give an estimation of whether it is compatible or not.

I got LDAP authentication working on the directory containing the wiki through the Apache web server. Now I am still running into

trouble automatically creating accounts on the mediawiki. While using an phpinfo page on the directory, I found that the

authentication information is present in the $_SERVER['REMOTE_USER'] and $_SERVER['PHP_AUTH_PW'] variables.

How can I feed that information into the wiki database to automatically create the user account?

Hi, I created a simple authentication extension that works in conjunction with PluggableAuth for the user to login automatically. Currently, I need two parameters: a username and a token. These parameters are generated by an external system that sends the data by hidden input. I can get the url data and authenticate correctly. But for security reasons I want to pass this data via $_POST and not via $_GET. But I cannot receive this data and store it in the session so that I can retrieve it in my authentication class. Basically, the user receives a link from a wiki page and Pluggableauth does the checks. But I can't find what code I can use to save the post in the session and retrieve it later. Does anyone have any examples of how to do this? Thanks!

@Cindy.cicalese

I am trying to upload some epub files to a private media wiki server. I have added the

$wgFileExtensions[] = 'epub';

to LocalSettings.php. When I try to upload I get the error:

File extension ".epub" does not match the detected MIME type of the file (application/zip).

Even when I select "Ignore any warnings" it refused to upload.

What can I do?

Lbundle (talk) 00:51, 1 November 2021 (UTC)

You could set Manual:$wgVerifyMimeType to false. This has security implications but should be fine if private server.

Personally i think we should be less strict with zip files. JAR is no longer a threat.

Hi, I need to send data from an external form with hidden fields sent via 'post' to authenticate with my extension that works in conjunction with PluggableAuth. How do I get these fields and use them in my extension? I've already tried sending the data to $_SESSION but it didn't work.

@BarbaRuivaRK Welcome to Mediawiki. See this Extension:PluggableAuth and i have read this. Maybe you won't get a hidden field in it.

I have some pages with iframe but by changing from PHP version these pages became blanco. I cannot delete them neither (only by accessing mysql).

Is there a way to detect these pages with iframes and to remove the iframes so I don't have to delete these pages and make them again ?

OK, I solved the problem by deleting the page Widget:Iframe from my wiki.

(it was a widget that allows you to embed any web page on your wiki page using an iframe tag.)

Now I can watch the pages again and remove the iframes manually.

Thanks anyway.

Enabling php error reporting might help to tell you why its happening to prevent similar things from happening in the future.

Although it sounds like your sorted, if something similar happens again, you can delete pags via the API