DiscourseSsoConsumer, a SSO extension for MediaWiki

plugin extras
1

DiscourseSsoConsumer is a MediaWiki extension that allows a MW site to authenticate users via the Discourse Connect Provider API (i.e., users type their passwords into Discourse). Originally released a year ago, version 2.0.0 was released yesterday. I figure it is time to give this extension its own topic here so that it is easier to find (versus the original lonely post in the SSO Provider topic: Using Discourse as an identity provider (SSO, DiscourseConnect) - #104 by mdoggydog).

It installs via composer. Installation/configuration instructions are in the README.

4 Likes
2

Is there a minimum version for Mediawiki for this to work?

3

For v2.0.0, the minimum MediaWiki is 1.35 (and it has not been tested on any newer version yet).

The extension was originally developed/tested with MW 1.31; v1.1.0 and v1.2.0 probably work with MW 1.31, but they have not been tested on it.

1 Like
4

@mdoggydog
I am using MediaWiki 1.37 and have set up this extension using composer. I am seeing the following error

[YidklSqHVG68-iRmgGiwzwAAAFA] /view/Special:PluggableAuthLogin Error: Call to undefined method MediaWiki\Auth\AuthManager::singleton()

Backtrace:

from /var/www/vhosts/mywebsite.com/httpdocs/w/extensions/DiscourseSsoConsumer/src/DiscourseSsoConsumer.php(132)
#0 /var/www/vhosts/mywebsite.com/httpdocs/w/extensions/PluggableAuth/includes/PluggableAuthLogin.php(36): MediaWiki\Extension\DiscourseSsoConsumer\DiscourseSsoConsumer->authenticate()
#1 /var/www/vhosts/mywebsite.com/httpdocs/w/includes/specialpage/SpecialPage.php(647): PluggableAuthLogin->execute()
#2 /var/www/vhosts/mywebsite.com/httpdocs/w/includes/specialpage/SpecialPageFactory.php(1366): SpecialPage->run()
#3 /var/www/vhosts/mywebsite.com/httpdocs/w/includes/MediaWiki.php(314): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#4 /var/www/vhosts/mywebsite.com/httpdocs/w/includes/MediaWiki.php(930): MediaWiki->performRequest()
#5 /var/www/vhosts/mywebsite.com/httpdocs/w/includes/MediaWiki.php(564): MediaWiki->main()
#6 /var/www/vhosts/mywebsite.com/httpdocs/w/index.php(53): MediaWiki->run()
#7 /var/www/vhosts/mywebsite.com/httpdocs/w/index.php(46): wfIndexMain()
#8 {main}
5

It appears that the AuthManager::singleton() method was deprecated in 1.35 and removed in 1.37.

I think I have fixed this now; please try the current dev-main version of this extension. (You can install it via composer, using “dev-main” as the version number.) It works for me on 1.35, and if it works for you in 1.37 then I will properly tag it as a bug fix release (e.g., 2.0.1).

1 Like
6

Thanks, this worked :+1:

7

Awesome, and thank you, too. Version 2.0.1 has been released.

1 Like
8

I have installed the app on my android phone i.e. PWA standalone. When I log in to my MediaWiki, it redirects and opens the discourse PWA and then it opens my MediaWiki URL in the PWA itself when it should redirect to the corresponding web browser. I think discourse isn’t properly detecting and redirecting to the corresponding web browser that initiated the login. This is not related to MediaWiki extension though, it’s related to how discourse handles redirects/external URLs. Is there any setting I can modify to get the login to work with the discourse progressive web app?

9

Sorry, I have zero experience with the Discourse PWA.

I imagine there is a fundamental flaw in the interaction of a PWA and Discourse as SSO Provider, however: whenever the SSO consumer wants to reauthenticate an already-logged-in-to-discourse user, it’s going to tell the client browser to redirect to the Discourse server, expecting the Discourse server to check the user’s existing cookies and redirect back to the consumer… and expecting all these redirects to happen silently in the browser without the user actually seeing anything except the final page load.

But, the PWA is registered with Android as an entirely separate application which is invoked for certain URL’s/domains, right? When the PWA redirects back to the original browser, how would the original browser know that this new link has anything to do with its original request? And how could Android know that it should only show the PWA to the user if the PWA actually needs input from the user? :philosoraptor: