Wikimedia Developer Support

Testing Wikimedia login for this Discourse instance

Hi, in the context of the Wikimedia Space program, we have commissioned the development of a Wikimedia login plugin for Discourse.

We have a first version of this plugin installed in this instance. Let’s test it!

I have given Discourse admin rights to @angus aka https://thepavilion.io/u/angus, developer of this plugin, so he can test this plugin better. Hi Angus!

2 Likes

I logged out, then I clicked the link for logging in. The “Login with Wikimedia” button is there. However, I get a new window with this message:

Redirecting to …

And it doesn’t seem to go anywhere.

2 Likes

Same result for me.

I click ‘Login with Wikimedia’ and get a popup window with ‘Log in using Wikimedia’ and a ‘Continue’ button, and clicking the button results in a POST request to https://discourse-mediawiki.wmflabs.org/auth/mediawiki which results in an empty Location: header being returned and the same page displayed again after a 302 redirect.

3 Likes

Hey guys! I’ll come in and check the setup of the plugin first thing tomorrow (GMT +10) and then update you on the usage and what we need to test.

You don’t mean to say you’re in Australia?! Hullo from Perth! (And equally so even if you’re in Vladivostok.)

Login with Phabricator does work. Login with Wikimedia same result as Quim. Thanks for commissioning development of Wikimedia login. Keep on trying, don’t give up. Ad

1 Like

Wikimedia login does not work for me on FF.

‘Login with Wikimedia’ --> ‘Continue’ --> Nothing happens*

*: there is activity (waiting, loading, reading, fetching etc.) in the background.

I saved the HAR file in case you need it.

Yep, exactly the same result here.

Hey guys,

I’m the developer who’s been working on this Discourse plugin. @samwilson I’m originally from Perth! I’m currently in Melbourne (although Valdivostock would be interesting :wink: ).

Now that the plugin is installed, there’s a few things we need to configure for it to work, in particular the OAuth consumer registration for this site. I’ve laid this out in the “Setup Notes” below.

My existing OAuth Consumer Registration is specific to my development environment, so we’ll need another for this site (and the produciton site). I could do that from my Wikimedia account, but it’d probably be best if it was from a more permanent or a non-individual-specific staff account.

Setup notes

OAuth Consumer Registration

The first thing you need is an approved OAuth Consumer Registration. This has two steps:

  1. Filling out the consumer registration form

  2. Getting your request approved

Consumer Registration Form

The form you need to fill out to is here: https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration. The fields should be filled out as follows:

  • Application: Can be anything, e.g. “WMF Discourse”

  • Consumer versions: 1.0

  • Application Description: Can be anything, e.g. “Discourse for WMF”

  • This consumer is for use only by <username>: leave this unchecked

  • OAuth “callback” URL: “<your domain>/auth/mediawiki/callback” For example https://discourse-mediawiki.wmflabs.org/auth/mediawiki/callback

  • Allow consumer to specify a callback in requests and use “callback” URL above as a required prefix: leave this unchecked

  • Contact email address: your email

  • Applicable project: leave this as *

  • Types of grants being requested: check “User identity verification only with access to real name and email address, no ability to read pages or act on a user’s behalf.”

  • Applicable grants: leave as is

  • Allowed IP ranges: leave as is

  • Public RSA key (optional): leave as is

  • Check the final checkbox.

Once you click “Propose consumer” make sure you make a note of the key and secret given to you.

Proposal Approval

To get your proposal approved you need to post a new topic in https://meta.wikimedia.org/wiki/Talk:Steward_requests/Miscellaneous using the template:

Subject:

OAuth approval request for <"Application" from your proposal>

Body:

{{oauthapprequest
| status = <!-- don't edit this line -->
| appname = <"Application" from your proposal> 
| version = 0.0.1
| publisher = <your username>
| consumer_key = <key given after your proposal was submitted>
}}

OAuth Site Administration

Once your OAuth proposal is approved you’re ready to set up Wikimedia Auth in Discourse. The following guide assumes that you’ll be using Wikimedia Auth as the sole method of authentication in Discourse (as a form of single-sign-on). It also assumes you have the discourse-wikimedia-auth plugin is installed.

Discourse Site Settings

Set the folowing site settings:

  • enable local logins: false (this turns off email / password login)

  • enable local logins via email: false (this turns off logging in via an email link)

  • email editable: false (this ensures the user’s email remains that provided by wikimedia)

  • username change period: 0 (this ensures the user’s username remains that provided by wikimedia)

  • ensure that none of the other oauth providers are enabled, i.e. google, twitter and facebook.

  • wikimedia auth enabled: true

  • wikimedia consumer key: “key” you obtained when you submitted your proposal

  • wikimedia consumer secret: “secret” you obtained when you submitted your proposal

  • wikimedia callback url: oob

  • wikimedia auth site: https://meta.wikimedia.org (you can change this to any wiki)

Usage Notes

User Property Ownership

As mentioned, the plugin assumes that Wikimedia OAuth will be the sole source of authentication, functioning as a form of single sign on. Like other single sign on systems, it assigns ownership over the primary identifying properties of the user to the source of authentication, specifically their email and username.

In short, the user’s Discourse email and username will be the same as the user’s Wikimedia email and username and cannot be set or changed in Discourse. Other user properties, such as the user’s real name or location, can be set and changed in Discourse.

One thing to note about usernames is that it is not possible to exactly transpose Wikimedia usernames into Discourse as the rules concerning usernames in a Wikimedia wiki are different from the rules concerning usernames in Discourse. These rules cannot be changed for our purposes (in either Discourse or in a Wikimedia wiki).

One key difference is that Wikimedia usernames can have spaces and brackets whereas Discourse usernames can’t. This means that AMcLeod (WMF) becomes AMcLeod_WMF in Discourse (albeit, Wikimedia wikis seem to treat spaces and underscores as the same thing). I can give you more detail on what exactly will change if it’s needed, but in the main Discourse allows fewer special characters in usernames than Wikimedia wikis.

The bottom line is the primary text content of the usernames will not change, but some usernames may change slightly to adhere to the Discourse username rules.

Note that Wikimedia usernames are still stored as-is (i.e. as-is on Wikimedia wikis, without the Discourse username rules applied) in the Discourse database (see “Data Storage” below), so if you need to exactly associate Wikimedia accounts with Discourse accounts for integration purposes, this is still possible.

Login Flow

The login flow works as follows, starting in Discourse.

User clicks on login or sign up button and they are redirected to the wiki the plugin is authenticating users on. On that wiki they see this modal.

After the user has clicked “Allow” they are redirected back to Discourse. Note that the user has to have confirmed their Wikimedia email to gain access. If they have not confirmed their Wikimedia email they see

This error message can be edited in Admin > Customize > Text Content: “login.authenticator_email_not_verified”

If they have confirmed their Wikimedia email they see the modal below. If the user has a “realname” associated with their Wikimedia account this field will be filled with that property, otherwise it is filled with an adapted version of their username.

After the user clicks “Create New Account”, their account is created.

If the user visits the “Account” section of their Discourse user account, they will only be able to edit their avatar and their real name. As mentioned, their username and email are “owned” by the Wikimedia auth provider and cannot be changed in Discourse.

They can still edit all the fields in the “Profile” section of their account.

Data Storage

In addition to being stored in the main user database tables, the user data recieved from Wikimedia when authourising the user is stored in the user_associated_accounts database table in Discourse.

  • Wikimedia Central ID

  • Wikimedia Email (in addition to its seperate storage in the user_emails database table, i.e. as the user’s Discourse email)

  • Wikimedia Username (in addition to its storage in the users database table, i.e. as the user’s Discourse username)

  • The following additional Wikimedia account data

    Account data

    {“aud”: “8d25ee8f61bf0930de67a3e2c076c979”, “exp”: 1564629219, “iat”: 1564629119, “iss”: “https://www.mediawiki.org”, “sub”: 58875557, “email”: “angus@mcleod.org.au”, “nonce”: “eL98x2zKqfzVVO1Loy5wBtw5VP0tBJF3H7ot2uFY3Q”, “grants”: [“mwoauth-authonlyprivate”], “groups”: ["*", “user”, “autoconfirmed”], “rights”: [“createaccount”, “read”, “edit”, “createpage”, “createtalk”, “writeapi”, “viewmywatchlist”, “editmywatchlist”, “viewmyprivateinfo”, “editmyprivateinfo”, “editmyoptions”, “translate”, “centralauth-merge”, “codereview-use”, “abusefilter-view”, “abusefilter-log”, “vipsscaler-test”, “flow-hide”, “flow-create-board”, “move-rootuserpages”, “move-categorypages”, “minoredit”, “editmyusercss”, “editmyuserjson”, “editmyuserjs”, “purge”, “sendemail”, “applychangetags”, “changetags”, “translate-messagereview”, “translate-groupreview”, “spamblacklistlog”, “lqt-split”, “lqt-merge”, “lqt-react”, “flow-lock”, “mwoauthmanagemygrants”, “move”, “collectionsaveasuserpage”, “collectionsaveascommunitypage”, “autoconfirmed”, “editsemiprotected”, “skipcaptcha”, “flow-edit-post”, “transcode-reset”], “blocked”: false, “realname”: “”, “username”: “AMcLeod (WMF)”, “editcount”: 0, “registered”: “20190710001640”, “confirmed_email”: true}, “access_token”: {“token”: “cc5718ae6755593cf4d6ed4dbb744068”, “params”: {“oauth_token”: “cc5718ae6755593cf4d6ed4dbb744068”, “oauth_token_secret”: “2d14b8a3fd0468ada618ab6346ea065e953f2ac1”, “oauth_callback_confirmed”: “true”}, “secret”: “2d14b8a3fd0468ada618ab6346ea065e953f2ac1”, “consumer”: {“key”: “8d25ee8f61bf0930de67a3e2c076c979”, “uri”: “https://www.mediawiki.org”, “http”: {“key”: null, “cert”: null, “port”: 443, “socket”: null, “address”: “www.mediawiki.org”, “ca_file”: null, “ca_path”: null, “ciphers”: null, “started”: false, “use_ssl”: true, “proxy_uri”: false, “cert_store”: null, “local_host”: null, “local_port”: null, “proxy_pass”: null, “proxy_port”: null, “proxy_user”: null, “max_retries”: 1, “max_version”: null, “min_version”: null, “ssl_context”: {“verify_mode”: 0, “verify_hostname”: true, “max_proto_version”: null, “min_proto_version”: 769}, “ssl_session”: {}, “ssl_timeout”: null, “ssl_version”: null, “verify_mode”: 0, “debug_output”: null, “open_timeout”: 30, “read_timeout”: 30, “sspi_enabled”: false, “verify_depth”: null, “proxy_address”: null, “proxy_from_env”: true, “verify_callback”: null, “continue_timeout”: null, “curr_http_version”: “1.1”, “last_communicated”: null, “keep_alive_timeout”: 2, “close_on_empty_response”: false}, “secret”: “7a406ad2b56736f3a6e6f8a78188f13be6b41499”, “options”: {“site”: “https://www.mediawiki.org”, “proxy”: null, “scheme”: “header”, “http_method”: “post”, “debug_output”: null, “oauth_version”: “1.0”, “authorize_path”: “/wiki/Special:Oauth/authorize”, “signature_method”: “HMAC-SHA1”, “access_token_path”: “/w/index.php?title=Special:OAuth/token”, “request_token_path”: “/w/index.php?title=Special:OAuth/initiate”}, “http_method”: “post”, “debug_output”: null}, “response”: {“age”: [“0”], “p3p”: [“CP=“This is not a P3P policy! See https://www.mediawiki.org/wiki/Special:CentralAutoLogin/P3P for more info.””], “date”: [“Thu, 01 Aug 2019 03:11:59 GMT”], “vary”: [“Accept-Encoding,X-Seven”], “pragma”: [“no-cache”], “server”: [“mw1322.eqiad.wmnet”], “expires”: [“Thu, 01 Jan 1970 00:00:00 GMT”], “x-cache”: [“cp1089 pass, cp2019 pass, cp5008 pass, cp5010 pass”], “x-varnish”: [“195253071, 298034681, 204381888, 231530485”], “connection”: [“close”], “set-cookie”: [“WMF-Last-Access=01-Aug-2019;Path=/;HttpOnly;secure;Expires=Mon, 02 Sep 2019 00:00:00 GMT”, “WMF-Last-Access-Global=01-Aug-2019;Path=/;Domain=.mediawiki.org;HttpOnly;secure;Expires=Mon, 02 Sep 2019 00:00:00 GMT”, “GeoIP=AU:VIC:Southbank:-37.83:144.96:v4; Path=/; secure; Domain=.mediawiki.org”], “x-analytics”: [“https=1;nocookies=1”], “x-client-ip”: [“119.225.53.170”], “content-type”: [“application/json”], “x-powered-by”: [“HHVM/3.18.6-dev”], “accept-ranges”: [“bytes”], “cache-control”: [“private, s-maxage=0, max-age=0, must-revalidate”], “server-timing”: [“cache;desc=“pass””], “backend-timing”: [“D=79569 t=1564629119573897”], “content-length”: [“986”], “x-cache-status”: [“pass”], “x-content-type-options”: [“nosniff”], “strict-transport-security”: [“max-age=106384710; includeSubDomains; preload”]}

There are a few things to note about this data storage.

Firstly, it is relevant to privacy matters, particularly in regimes such as the GDPR. This is a subset of a broader issue which has been addressed in the context of Discourse in a few different ways. For further on this topic see the following:

Secondly, it also may be useful for any future integrations you want to have between Discourse and any Wikiemdia wiki.

The type of account data returned by the server is determined by the “Types of grants being requested” field in the OAuth Consumer Proposal (above). We selected the one we did as this is described as returning the user’s email and name which we need. It also returns a fair amount of other user information however.

If we want Discourse to be storing less user information, there may be a change we can make to the OAuth Consumer Proposal grant type (i.e. a different option that returns email and name, but not all the additional information noted above).

3 Likes

Thank you so much @angus! And sorry for jumping the gun so quickly, I was just too excited. :slight_smile:

OK. Requested at https://meta.wikimedia.org/wiki/Talk:Steward_requests/Miscellaneous#OAuth_approval_request_for_Wikimedia_Developer_Support

The request has been quickly approved by @Tgr. Great, thank you!

All done. Wikimedia login should work!

But… can someone other than me test? I don’t dare logging out without knowing whether logging in will work. I had deactivated Phabricator and GitHub logins, as instructed.

If anyone gets locked out, you can report the problem at https://discuss-space.wmflabs.org/t/wikimedia-login/78.

It works! (BTW, @qgil, why can’t I comment with less than “20 characters.” I’d wanted to write “It works!” but I was not allowed to post.)

2 Likes

Thank you @Ammarpad, you won a gold medal! :1st_place_medal:

Let’s see if we get a good sample of users logging in successfully.

(20 characters, it’s a configurable setting, we can discuss somewhere else.)

It worked at me as well. :+1:

(I agree with @Ammarpad about the 20 characters limit, and others reported me already as well.)

2 Likes

Logged in succesively through Wikimedia. Congratulations!

2 Likes

So far we have existing users being able to log in. We still need to check whether new users can register new accounts with their Wikimedia login.

A third scenario would be users willing to get an account here and having to create a Wikimedia account during the process.

We will test all these scenarios in depth of course.

Ciaaao from me as well

2 Likes

This is prolly not for this thread, but, do we really need the OAuth popup every single time? Isn’t there just a thing like permanent authorization and/or at least “remind this for 90 days” or something?

Hmm. I logged in with my SamatBot account in a private browser window (I typed in my username and password), and…
I am here as Samat, not as SamatBot. Is this behavior normal? :thinking:

What is the difference between the Log in and the Sign up buttons in our case? They apparently result the same process.