Extension talk:PluggableAuth/2018

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.

Prevent re-authentication when visiting /index.php?title=Special:Login&returnto=Main_Page?

Hi,

I'm using the OpenID Connect extension with a setup like this:

- anonymous users are allowed to read, but they're not allowed to edit or to register

- $wgPluggableAuth_EnableAutoLogin is disabled so that anonymous users that cannot authenticate can read the wiki

- the users that can log in usually access the wiki while it is iframed in the site that serves as the OP

- I'm using /index.php?title=Special:Login&returnto=Main_Page as the iframe src to ensure that these users are automatically logged in

Unfortuately, visiting /index.php?title=Special:Login&returnto=Main_Page causes the OpenID Connect extension to re-authenticate against the IdP, even if the user was already logged in. This causes an annoying delay of several seconds each time the user clicks on the navigation link that opens the wiki in the iframe.

Is there any way to prevent re-authentication when the user is already logged in, e.g. with another Special site, or a parameter for Special:Login? As far as I can tell from includes/specialpage/LoginSignupSpecialPage.php, the core code does have the behaviour I want:

                /*
                 * In the case where the user is already logged in, and was redirected to
                 * the login form from a page that requires login, do not show the login
                 * page. The use case scenario for this is when a user opens a large number
                 * of tabs, is redirected to the login page on all of them, and then logs
                 * in on one, expecting all the others to work properly.
                 *
                 * However, do show the form if it was visited intentionally (no 'returnto'
                 * is present). People who often switch between several accounts have grown
                 * accustomed to this behavior.
                 *
                 * Also make an exception when force=<level> is set in the URL, which means the user must
                 * reauthenticate for security reasons.
                 */
                if ( !$this->isSignup() && !$this->mPosted && !$this->securityLevel &&
                         ( $this->mReturnTo !== '' || $this->mReturnToQuery !== '' ) &&
                         $this->getUser()->isLoggedIn()
                ) {
                        $this->successfulAction();
                }

Is it possible that PluggableAuth accidentally breaks this behaviour? Martin von Wittich (talk) 23:37, 20 January 2018 (UTC)

I haven't noticed that behavior, but I may not have tried that path. Could you please add a task in Phabricator for this, so I don't lose track of this request? Then, I will try to reproduce/diagnose the behavior. Thanks! Cindy.cicalese (talk) 23:30, 22 January 2018 (UTC)

I have now reproduced this behavior and confirmed that the code above is executed. However, the redirect location that is set inside successfulAction() is later overwritten due to the logic of the code that follows it in the case of Authentication Providers that require their own redirect. A quick fix would be to add a "return" inside that if statement at the end, but the implications of that change would have to be assessed. Could you please create a Phabricator ticket to track this bug? Thanks! Cindy.cicalese (talk) 13:18, 24 January 2018 (UTC)

Hi Cindy, thanks for the reply! I've created the task: https://phabricator.wikimedia.org/T185702 Martin von Wittich (talk) 15:00, 25 January 2018 (UTC)

Using with bot accounts?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I am hoping to setup a wiki so that users _have_ to login via SAML, and are sent to the login page automatically.

$wgPluggableAuth_EnableAutoLogin = true;

$wgPluggableAuth_EnableLocalLogin = false;

I also have bots that need to use the media wiki api. Unfortunately, with the above settings, the bots can't log in, and receive the error below.

Failed - The supplied credentials could not be authenticated.

(they are logging in using user/pass, although I suspect OAuth would have the same issue because they're still local logins)

The problem appears to be that PluggableAuth is (rightfully) removing LocalPasswordPrimaryAuthenticationProvider from $GLOBALS['wgAuthManagerAutoConfig']['primaryauth']

This feels like more of a problem with media wiki itself and not with PluggableAuth. Is there some way around this? Jgrevzie (talk) 00:27, 4 February 2018 (UTC)

I have had several people report this issue, but I have not had a chance to research it further. Have you tried the settings at Manual:Bot passwords? I'd be interested to know if those settings are compatible with PluggableAuth. Cindy.cicalese (talk) 01:22, 6 February 2018 (UTC)

Thank you for responding!! I have tried those settings. Unfortunately they don't help with this issue. Looking at the code for MW, it appears that bots are logged in as local users. PluggableAuth removes MediaWiki\Auth\LocalPasswordPrimaryAuthenticationProvider in PluggableAuthHooks.onRegistration ( $wgPluggableAuth_EnableLocalLogin = false; ). After that happens MediaWiki can't find an authorisation provider to login a bot.

Would a possible solution be to to change PluggableAuth so that it always forwards to the auth provider if $wgPluggableAuth_EnableAutoLogin = true; ? Currently it does not do this if $wgPluggableAuth_EnableLocalLogin = true; Jgrevzie (talk) 06:58, 6 February 2018 (UTC)

I asked someone familiar with the implementation of bot passwords and was told that bot passwords circumvent the normal authentication process. The bot password mechanism uses a session provider, BotPasswordSessionProvider, rather than an authentication provider, so the code in PluggableAuth, which does not use a session provider, should not conflict. LocalPasswordPrimaryAuthenticationProvider should not be necessary if you are using bot passwords, so removing it should not be an issue.

If you disable PluggableAuth, you able to log in with your bot, correct? So, you're sure it is PluggableAuth causing the issue? Cindy.cicalese (talk) 20:31, 6 February 2018 (UTC)

Cindy, sorry for not getting back to you sooner. Essentially the problem I was trying to solve was to allow a bot user to access images via the MW api in a protected wiki. Unfortunately I was never able to get this working cleanly. I was able to achieve it by hacking the image auth script. What you said above was correct. I mistakenly felt that PluggableAuth was affecting bot login. Thanks again for your help. Jgrevzie (talk) 05:53, 15 May 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Disabling the local login per flag

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

For testing purposes I manually set the flag:

$wgPluggableAuth_EnableLocalLogin = "true";

which showed me the local login. Now when I set it to false like this

$wgPluggableAuth_EnableLocalLogin = "false";

the local login is still shown and possible. Only when I take that like out completely (e.g. by commenting it out) then the local login is disabled.

---

MediaWiki 1.31.0 PHP 7.2.7-0ubuntu0.18.04.2 (apache2handler) MySQL 5.7.22-0ubuntu18.04.1 ICU 60.2

PluggableAuth 5.4 (300ac44) 07:28, 14 April 2018 SimpleSAMLphp 4.1 (1e36e1d) 19:45, 26 March 2018 2A00:8A60:1:F0:A821:519B:AB43:9BBD (talk) 14:26, 17 July 2018 (UTC)

The problem lies in that the value provided to $wgPluggableAuth_EnableLocalLogin must be a boolean, literal. It must not be placed between quotes ("). Instead you should use

$wgPluggableAuth_EnableLocalLogin = true;

and

$wgPluggableAuth_EnableLocalLogin = false;

—Mainframe98 _talk 14:31, 17 July 2018 (UTC)

Man that was fast. Thank you for the quick response! What a stupid misstake :D 2A00:8A60:1:F0:A821:519B:AB43:9BBD (talk) 14:39, 17 July 2018 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Autologin redirects to home page even when clicking on a link pointing to another page

Hello,

Thank you for this nice plugin. I have used your extension in conjunction with LDAP to enable SSO on our intranet. My issue is the following: the autologin feature works in the sense that users are automatically logged in when they access the wiki, However, if they are sent a link pointing a page other than the welcome page, they always get redirected to the home page the first time they click on the link. Once the browser is opened and they are authenticated, clicking on the link will get them to the right page. I have started debugging and it looks as if original URL is lost in the doBeforeInitialize.

I am using MW 1.27 (LTS).

Edited at 16h27 on 2018-07-23

Note my URLs are of the form http://xx.xx.xx.xx/index.php?title=test_page Ti infotrad (talk) 11:10, 23 July 2018 (UTC)

For the record, adding the returnto variable to the request in PluggableAuthHooks::doBeforeInitialize as per code below solved my issue.

$oldTitle = $title;

+$request->setVal( 'returnto', $oldTitle );

$title = Title::newFromText( "UserLogin", NS_SPECIAL ); Ti infotrad (talk) 11:10, 25 July 2018 (UTC)

Interesting. Please feel free to submit a patch in gerrit to include that line. Thanks! Cindy.cicalese (talk) 17:07, 25 July 2018 (UTC)

This is fixed in the GIT master. 1.128.108.237 (talk) 00:59, 2 December 2019 (UTC)

opt-in for GDPR possible?

In respect to the GDPR and privacy discussion: Is it possible to have an extra page with opt-in button the first time, a user is authenticated via PluggableAuth?

Optimally this page would automatically pop up again for every user, if the version number of a configurable wikipage is increased (-> the page is edited).

This would enable to inform the user about the use and processing of his data and be compliant with the opt-in requirement of the GDPR, without having him/her opt-in for every edit.

Using Mediawiki 1.31 with PluggableAuth and SimpleSAMLphp to authenticate against a Shibboleth IdP. 2A00:8A60:1:F0:5995:2A21:BB0C:7B74 (talk) 12:58, 25 July 2018 (UTC)

Perhaps Extension:UserAgreement would be useful for this purpose? Cindy.cicalese (talk) 16:57, 25 July 2018 (UTC)

Thank you, Cindy, for the tipp - It looks like that extension would perfectly. After I trying that out, I will make sure to link it into the GDPR discussion at the appropriate place. 2A00:8A60:1:F0:60:C42:9C9A:D5D2 (talk) 09:14, 31 July 2018 (UTC)

Password-based cURL Authentification

Hello,

Thank you for this plugin! I am new to MediaWiki and am still wondering whether I can use your extension.

I am trying to create a simple password-based external Auth method. Users should be forced use an existing external account for logging in, unfortunately without SSO.

The Extension should process username and password from the mediawiki login form, using SSL and cURL to send them to the external API (somewhat similar to the outdated extension Extension:CentralAuth). Based on the API's response the user is logged in (or created first if non existent).

I have already written similar extensions for WordPress and phpBB, but these were simply hook-based.

I understood so far that i need a PasswordPrimaryAuthenticationProvider and use MediaWiki\Auth\PasswordAuthenticationRequest.

Is this still possible with PluggableAuth or do I have to start from the scratch? Because you don't seem to use the classes mentioned above.

Thank you very much in advance! Rafer.Alston (talk) 07:15, 5 November 2018 (UTC)

You should be able to use PluggableAuth by configuring a username and password field in $wgPluggableAuth_ExtraLoginFields. Instructions for accessing the user values in those fields are at Extension:PluggableAuth#Accessing Extra Login Fields. You should not need to use a PasswordPrimaryAuthenticationProvider or MediaWiki\Auth\PasswordAuthenticationRequest since the interaction with the underlying MediaWiki authentication system is handled by PluggableAuth and you are not using the MediaWiki database to hold the password. Cindy.cicalese (talk) 13:33, 5 November 2018 (UTC)

Thank you very much!

Now my cURL auth extension works just fine thanks to your fantastic plugin!

At the moment I define $wgPluggableAuth_ExtraLoginFields in LocalSettings.php and am experiencing two minor problems:

1. Unfortunately, I cannot define any text output in the loginform. The HTML Form parameters label, help or placeholder as given in the HTMLForm specs don't work, neither as string nor i18n message. This leaves my extra login fields blank without any description. Other i18n messages work fine, e.g PluggableAuth_ButtonLabelMessage. Are these parameters just not supported by AuthManager?
2. I would like to define PluggableAuth_ExtraLoginFields in the extension.json of my extension instead of LocalSettings.php. Unfortunately defining it in the config section produces an exception that the variable is already set by another extension (Pluggable Auth). Working with attributes does not work either. Defining e.g. PluggableAuth_Class in extension.json works fine. Rafer.Alston (talk) 14:33, 11 November 2018 (UTC)

I'm glad the functionality is working for you! You should be able to specify text labels in the login form. For example, the following works for me:

$wgPluggableAuth_ExtraLoginFields = [

    'username' => [

      'type' => 'string',

      'label' => 'userlogin-yourname'

    ],

    'password' => [

      'type' => 'password',

      'label' => 'userlogin-yourpassword',

      'sensitive' => true,

    ],

  ];

Right now it isn't possible to override PluggableAuth_ExtraLoginFields in extension.json like PluggableAuth_Class can be because of the way I specified it in extension.json. I will try to find time to change that. I would also consider a pull request for that functionality. Cindy.cicalese (talk) 20:03, 11 November 2018 (UTC)

Thanks again. I found the HTML Form docs confusing as 'label' was used for a direct string and 'label-message' for i18n messages. 'label' with i18n message as in your example works great for me now, too.

as for the possible override of PluggableAuth_ExtraLoginFields - I will make a pull request in time. Rafer.Alston (talk) 20:27, 14 November 2018 (UTC)

You are correct that the PluggableAuth documentation was misleading. I double checked, and while the array is similar to the HTMLForm field descriptor array, it is not identical. The core authentication code processes the array slightly to turn it into an HTMLForm field descriptor array. I corrected the PluggableAuth documentation to point to the documentation for AuthenticationRequest:getFieldInfo(), which correctly describes the format of the array. Thank you for catching that. Cindy.cicalese (talk) 13:43, 16 November 2018 (UTC)

I also noticed that the value of label can be a message name or it can be, as described in the documentation, an actual message object. So, the following will work as well:

$wgPluggableAuth_ExtraLoginFields = [

    'username' => [

      'type' => 'string',

      'label' => wfMessage( 'userlogin-yourname' )

    ],

    'password' => [

      'type' => 'password',

      'label' => wfMessage( 'userlogin-yourpassword' ),

      'sensitive' => true,

    ],

  ]; Cindy.cicalese (talk) 13:47, 16 November 2018 (UTC)

Missing 5.6 release tag?

The extension page mentions current release 5.6 but I do not see such a release tag on Github. Did I miss something? Planetenxin (talk) 09:05, 13 November 2018 (UTC)

Thanks for pointing that out. The release tags for versions 5.5 and 5.6 never got pushed. They are there now. Cindy.cicalese (talk) 17:34, 13 November 2018 (UTC)

How to limit access to a group

I'm running MW 1.31 with pluggableauth and simplesaml extensions. I have * autocreateaccount in the LocalSettings.php and using simplesaml attribute to map wikiadmin to sysop. Is there a way to restrict account creation to those in the wikiadmin group? Currently, any account that can authenticate has access. 107.141.114.14 (talk) 05:42, 28 November 2018 (UTC)

Yes, you can use an authorization plugin with PluggableAuth to limit the set of authorized users to a subset of those that can be authenticated. For example, see Extension:Email Authorization and Extension:LDAP Authorization. Cindy.cicalese (talk) 13:34, 28 November 2018 (UTC)

Hi Cindy,

Is there not a way for the PluggableAuth with SimpleSAMLphp extensions to use the $wgSimpleSAMLphp_GroupMap attribute and deny access if not a member of a specified group? Per your suggestion, I'm attempting to configure LDAPAuthorization and LDAPProvider, but I'd rather not use LDAP at all since the group attributes are being passed via SAML. 38.91.126.101 (talk) 17:00, 12 December 2018 (UTC)

That functionality does not currently exist, but it should be straightforward to create a SAMLAuthorization plugin to do this. It could be modeled after EmailAuthorization, with the email-based functionality replaced by SAML group-based functionality. It could be even simpler if you don't need the list of groups to be configurable from the user interface, in which case the authorized groups would be specified in a global configuration variable and you could eliminate the special pages. Cindy.cicalese (talk) 18:05, 12 December 2018 (UTC)

That's unfortunate for me and I have never made a plugin before. I don't think I need the groups configurable from the user interface and I like simple. Are you saying that a setting in the LocalSettings.php is all I need or do I still need a plugin modeled after EmailAuthorization and replaced with SAML functionality? Any chance you are interested in making this plugin or modifying your SimpleSAMLphp extension? 38.91.126.101 (talk) 18:47, 12 December 2018 (UTC)