DiscourseSsoConsumer, eine SSO-Erweiterung für MediaWiki

DiscourseSsoConsumer ist eine MediaWiki-Erweiterung, die es einer MW-Site ermöglicht, Benutzer über die Discourse Connect Provider API zu authentifizieren (d. h. Benutzer geben ihre Passwörter in Discourse ein). Ursprünglich vor einem Jahr veröffentlicht, wurde gestern die Version 2.0.0 veröffentlicht. Ich denke, es ist an der Zeit, dieser Erweiterung hier ein eigenes Thema zu geben, damit sie leichter zu finden ist (im Gegensatz zum ursprünglichen einsamen Beitrag im SSO Provider-Thema: Use Discourse as an identity provider (SSO, DiscourseConnect) - #104 by mdoggydog).

Die Installation erfolgt über composer. Installations-/Konfigurationsanweisungen finden Sie in der README.

5 „Gefällt mir“

Gibt es eine Mindestversion für Mediawiki, damit dies funktioniert?

Für v2.0.0 ist die minimale MediaWiki-Version 1.35 (und sie wurde noch nicht auf neueren Versionen getestet).

Die Erweiterung wurde ursprünglich mit MW 1.31 entwickelt/getestet; v1.1.0 und v1.2.0 funktionieren wahrscheinlich mit MW 1.31, wurden aber nicht darauf getestet.

1 „Gefällt mir“

@mdoggydog
Ich verwende MediaWiki 1.37 und habe diese Erweiterung mit Composer eingerichtet. Ich sehe den folgenden Fehler

[YidklSqHVG68-iRmgGiwzwAAAFA] /view/Special:PluggableAuthLogin Fehler: Aufruf der undefinierten Methode 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}

Es scheint, dass die Methode AuthManager::singleton() in 1.35 als veraltet markiert und in 1.37 entfernt wurde.

Ich glaube, ich habe das jetzt behoben; bitte probieren Sie die aktuelle dev-main-Version dieser Erweiterung aus. (Sie können sie über Composer installieren, indem Sie „dev-main“ als Versionsnummer verwenden.) Sie funktioniert bei mir unter 1.35, und wenn sie bei Ihnen unter 1.37 funktioniert, werde ich sie ordnungsgemäß als Bugfix-Release kennzeichnen (z. B. 2.0.1).

1 „Gefällt mir“

Danke, das hat funktioniert :+1:

Großartig, und danke Ihnen auch. Version 2.0.1 wurde veröffentlicht.

1 „Gefällt mir“

Ich habe die App auf meinem Android-Telefon installiert, d.h. PWA-Standalone. Wenn ich mich bei meinem MediaWiki anmelde, wird es umgeleitet und öffnet die Discourse PWA und dann öffnet es meine MediaWiki-URL in der PWA selbst, obwohl es zum entsprechenden Webbrowser weiterleiten sollte. Ich glaube, Discourse erkennt und leitet nicht richtig zum entsprechenden Webbrowser weiter, der die Anmeldung initiiert hat. Dies hat nichts mit der MediaWiki-Erweiterung zu tun, sondern damit, wie Discourse Weiterleitungen/externe URLs behandelt. Gibt es eine Einstellung, die ich ändern kann, damit die Anmeldung mit der Discourse Progressive Web App funktioniert?

Entschuldigung, ich habe keine Erfahrung mit der Discourse PWA.

Ich stelle mir eine grundlegende Schwäche in der Interaktion einer PWA und Discourse als SSO-Anbieter vor. Wenn der SSO-Konsument einen bereits bei Discourse angemeldeten Benutzer erneut authentifizieren möchte, wird er den Client-Browser anweisen, zum Discourse-Server umzuleiten, wobei erwartet wird, dass der Discourse-Server die vorhandenen Cookies des Benutzers überprüft und zurück zum Konsumenten umleitet … und erwartet, dass all diese Umleitungen im Browser lautlos erfolgen, ohne dass der Benutzer außer dem endgültigen Seitenaufruf etwas sieht.

Aber die PWA ist bei Android als eigenständige Anwendung registriert, die für bestimmte URLs/Domänen aufgerufen wird, richtig? Wenn die PWA zurück zum ursprünglichen Browser umleitet, woher weiß der ursprüngliche Browser, dass dieser neue Link etwas mit seiner ursprünglichen Anfrage zu tun hat? Und woher weiß Android, dass es dem Benutzer nur die PWA anzeigen soll, wenn die PWA tatsächlich eine Eingabe vom Benutzer benötigt? :philosoraptor: