Patch applied to the branches that match MediaWiki's supported versions.

@Osnard @Metaldaze80 Thank you both for your development and testing on this issue. I believe all of the permission checks are happening in ways that do not produce an infinite loop now.

In T369974#11180246, @Osnard wrote:

FYI: I have created https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Auth_remoteuser/+/1188293 as an proposal. Have set it to WIP, as I didn't have time to test it yet. Open for discussion.

Sorry about that! That check should also be moved like the other one.

The composer.json best practices manual encourages us to allow other, newer versions of composer/installers to avoid conflicts.

Thank you for fixing this issue! Backported to the REL1_42 branch and merged manually.

Thank you @Osnard for the fix and everyone else who discussed the issue. The fix has been merged and should be available now in the 1.43, 1.44 and master branches.

It looks like the changes to the constructor cause problems for plugins like Auth_remoteuser. Is there a migration guide on how we're supposed to correctly implement these changes? Or would you be willing to help @thiemowmde fix https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Auth_remoteuser/+/1185481 ?

Thanks @Osnard! If someone is logging in using Auth_remoteuser, does the fix still allow them to successfully log in? Or does it essentially turn off the Auth_remoteuser SessionProvider?

@Osnard @Metaldaze80 I have updated https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Auth_remoteuser/+/1181135 to try and complete the patch. If the infinite loop is resolved and turning the createaccount setting on/off has an effect, then I think this is an overall improvement over the current version. Thank you for your efforts!

@JeredF It's definitely the experience piece that's the limiting factor. Between true and false, the temporary workaround would be to "show the link even if people can't use the link". I'm living in a figurative construction zone right now, so if someone can open a change in the software system, I can review and approve it.

I think those changes are a perfect workaround. The purpose of the checks is to answer the question: "Does the current user (anonymous or not) have permission to create an account?" Manually setting those to true or false efficiently skips the part where the software would check the configuration settings. So if the answer to those access questions was always going to be true or false, then you're saving time.

Here's a much safer temporary workaround: Replace !$user->isAllowed( 'createaccount' ) with true or false within the refreshSessionInfo() method in UserNameSessionProvider.php. true would mean "Users are not allowed to create accounts".

Yes, If that code is at the top of the method, then the function will only run once. I don't know what effect that will have in general.

Copied from T369974

I think Change 966657 from this tracker item may have caused a regression that creates an infinite loop when a SessionProvider calls User->isAllowed in the refreshSessionInfo method. I'm not sure what the correct answer is here, so I'm hoping someone here might know.

Regression was caused by dfc691bfc52 "Migrate callers of deprecated method BlockManager::getUserBlock()" (T345683). In includes/Permissions/PermissionManager.php, the user rights cache was modified. My guess is that the caching stopped working and now the user rights checks run multiple times when a permission check is done within a SessionProvider.

Thank you @ChristianHeusel! If the maximum time is happening in significantly different places each time, then it probably means that there is an unexpected infinite loop between core code and the extension code. This makes sense for it to be in the registered hook. The hook itself is probably calling core code that - in turn - calls the hook again.

Thank you! That's a very helpful link.

I like this idea. As far as implementation, I would expect that an anonymous function is configured that will receive the current set of roles and the user object. The anonymous function could then use the user object information to determine which roles the user should have, and return the new set of roles.

No feedback from requester.

Sorry @Opoplawski, this is indeed a concern if you have PHP Deprecated messages enabled. The issue was fixed in REL1_41. The fix can be backported/cherry-picked to REL1_39. I do not have my development environment configured for this currently, so maybe you could convince the fix author to open a Code Review for backporting the fix to REL1_39.

@ChristianHeusel Which version of Auth_remoteuser are you using? Did it get updated at the same time as Mediawiki itself so that the matching REL1_42 version is being used?

Closing as resolved because the relevant configuration documentation was referenced.

@Kerb5wikE Does upgrading to the version of Auth_remoteuser that is designed for your version of Mediawiki resolve the issue?

By default, the link to the Logout special page is removed, because it would not do anything useful. If you have a better location for the Logout action that would do something useful, please follow the documentation in the README.md for how to configure the Logout URL: https://phabricator.wikimedia.org/diffusion/EARU/browse/master/README.md$225

Thanks @Umherirrender for addressing these issues in:

• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Auth_remoteuser/+/919439
• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Auth_remoteuser/+/916704

Is it correct that:

I don't think that the version was purposefully limited, so it makes sense to relax the restriction. It seems like the options to allow Composer 2.x would be ^1.0.1|^2 or >=1.0.1. As this plugin does not typically need regular changes, I think the open-ended version requirement would be best. We're not doing anything extremely complicated with our composer configuration, so it will likely be forward-compatible with the eventual Composer 3.

Thank you @Claashk - this was just the push I needed to learn more about the gerrit workflow.

That bug was fixed by in April 2019: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Auth_remoteuser/+/1436b981d6ff721cb7e0072cf32779d56ce03f45%5E%21/

The change has been merged. It's not letting me cherry-pick through gerrit (complains about a merge conflict). It seems like this fix would needed to be applied to REL1_32 also, right? Which release of Mediawiki added the array type check?

That's great to hear! Thank you for testing the change.

I'm not sure if this is the problem, but would you be willing to try moving the wfLoadExtension call to the end. In @Ninopul's example, this would look more like:

$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['autocreateaccount'] = true;
$wgAuthRemoteuserUserName = 'User005';
wfLoadExtension( 'Auth_remoteuser' );

@Enst80 Now that those tasks are all closed, do you want to release another version?

@Enst80 Understood. I uploaded a new patch set to provide an example of how it might be simpler. I hope you like it!

Is this commit in Gerrit somewhere?

Another option is to use the Special Page name as the array key and boolean true as the value. That would allow the use of the union operator without incurring duplicates. The foreach would need to be modified to match:

foreach ( $disableSpecialPages as $page => $disable )

Seems like a simple fix and it will address the specific issue. Nice find!

Hooray! Thank you both for making this milestone possible.

Stefan has done an amazing job with this. If anyone knows how we can get this change merged, please respond. Thank you.