Page MenuHomePhabricator

Add OAuth login to mailman for accessing list memberships/archive viewing
Open, LowestPublic


Can login to phabricator using oauth, but not to the mailing lists. Please add support.

Mailman3 uses for OAuth, someone will need to write a MediaWiki provider for it.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Aklapper changed the task status from Open to Stalled.Apr 8 2020, 8:12 AM
Aklapper removed a subscriber: Wikimedia-Mailing-lists.

What is "login to mailing lists"? Is this about the website ? Or emails? Or something else?
Please read and provide clearer steps.

Yes,, login is required to change preferences or view archives.

Peachey88 added a subscriber: Peachey88.

It looks like upstream mailman doesn't support this, And I can't see any upstream tasks about implementing this feature.

A cost benefit analysis would have to be looked at if it was something the WMF wanted to implemented and then feature maintain, going foward.

We are also still using a old 2.X release, Once we upgrade to 3.X they use a single user account principal across list memberships, which might improve the user experience a bit.

Peachey88 renamed this task from add oauth login to mailing lists to Add oauth login to the mailman package for accessing list memberships/archive viewing.Apr 10 2020, 5:49 AM

There are hundreds of lists and each one has different admins and different users and different settings who is allowed to see archives. This can not really be solved with a single login, it would need to be way more complex.

If you are talking about one specific list there is always the option to ask your list admins whether they could just make the archives public so no login is required in the first place.

mailman3 supports OAuth through the django-allauth library. Someone will need to write a MediaWiki provider for it, see - the source code is at

Once that's done we can look into deploying it.

Legoktm renamed this task from Add oauth login to the mailman package for accessing list memberships/archive viewing to Add OAuth login to mailman for accessing list memberships/archive viewing.Mar 26 2021, 7:57 AM
Legoktm changed the task status from Stalled to Open.
Legoktm updated the task description. (Show Details)

There's a django-social-auth plugin for MediaWiki, maybe that helps with writing the django-allauth one (see T155945: Review Mediawiki OAuth backend for python-social-auth).

If someone more knowledgeable about OAuth would like to work with me on this during the hackathon, I can bring knowledge about the Mailman bits.

How would this work exactly? You are logged in if you can identify as a Wikimedia users whose email address is the (primary? any?) email address of a Mailman account?

I think so, but I haven't really looked into it yet. Both and have some providers set up, we can test what the flow is there or enable it on is the brief Mailman documentation on the subject, it doesn't really say much except "Make sure that the one you choose provides “email” as part of user data, otherwise it won’t work with Mailman. e.g. Twitter doesn’t give out emails."

Seems straightforward as long as there is no need to tie accounts to each other (and this handle user renames, email address changes etc) and Wikimedia authentication is only used as proof of present-time ownership of the email address.

@Chicocvenancio expressed interested on working on this during the hackathon as well :) Should we pick a time tomorrow to start working on this?

@Tgr created

I cherry-picked it to the 0.38.0 version that Debian Buster has packaged (no conflicts) and then applied it on mailman03 with patch (will do a proper Debian package later) and then I realized I could've just copied the files in place, oh well.

I added the configuration:

    'wikimedia': {
        'DOMAIN': '',
        'APP': {
            'client_id': '93b852b24d46f45005d040f6d7fb0a10',
            'secret': '<redacted>',

But that gave me an internal error because there was no SocialApp row. I then went into the Django admin panel, created a new app with the same client id and secret, and there it was!

I then was able to link my account and login via "Wikimedia"! I think the app needs to be approved before others can use it though.

  • It would be much nicer if we can set the OAuth keys in the puppetized config file instead of inserting them into the DB.
  • We need an icon for "Wikimedia"
  • This seems to be account linking, not "proof of present-time ownership of the email address"...

I tried to log in with an account with an unconfirmed email address (which is the one major security concern with email-based OAuth with Wikipedia - see also T283456). While the login does not work (the user just lands in a signup form with the email field empty), and while I don't think this is really specific to OAuth, the handling of unconfirmed email is awkward: if user A registers with fake email address and is pending verification, user B who actually owns will be rejected from SUL login with "An account already exists with this e-mail address. Please sign in to that account first, then connect your Wikimedia account." error message.

This also means we won't be able to connect more than one Wikimedia account to the same email / Mailman account, which is mildly annoying but not much we can do about it.

  • We need an icon for "Wikimedia"

Is that something the allauth provider should handle? I did not see an option for that. There is a get_brand() method which the description says has something to do with logos, but it just returns an ID string.

  • This seems to be account linking, not "proof of present-time ownership of the email address"...

Yeah, that's unfortunate but I doubt we have any influence over it. And it shouldn't make much difference for most users (changing your email address will be a bit annoying, but you can always manually unlink the account).

As discussed on IRC, we should probably make a generic MediaWiki provider, not a Wikimedia provider. is the renamed version. Let me know what should be improved or if you think it's ready to be submitted upstream.

The logos appear to come from, so we'll need to submit a 24x24 MW logo there (and patch our version).

I'll deploy the renamed version later today, it looks good to me for submitting upstream.

Is there a standard list of test edge cases to try out? Like you already tried unconfirmed email, then maybe a linked account that gets renamed?

Is there a standard list of test edge cases to try out?

Account rename - Django uses the central ID as internal identifier, but the username is used as display name. Whether that updates, and whether it's a problem if it doesn't (can it be fixed manually) would be good to know.

(Confirmed) email address change, to either an unclaimed address or an address belonging to another Mailman user. My guess is this will have no effect (as you said, the email is only used for account linking) and users will to unlink and re-link their Wikimedia account if they want to use it to log into a different Mailman account. Probably not much real-world significance, when you change email address for one account, you likely want to change it for the other too.

In theory, (central) user ID change, but we don't use UserMerge on Wikimedia wikis.

Do we want some sort of formal security review for this, BTW?

Do we want some sort of formal security review for this, BTW?

I asked @sbassett on IRC and he suggested filing bug asking for a non-blocking, due-diligence review.

I uploaded python3-django-allauth 0.44.0+ds-1~bpo10+1 to apt.wm.o yesterday, it's a backport of the 0.44.0 version in bullseye plus Tgr's patch on top. I'll edit the task to create a checklist for next steps.

The appstream patch was merged, will be presumably released with 0.45 (maybe some time around the end of the year, based on their average release frequency).