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

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.

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 https://django-allauth.readthedocs.io/en/latest/providers.html - the source code is at https://github.com/pennersr/django-allauth

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

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 https://mail.python.org/accounts/login/?next=/mailman3/lists/ and https://lists.mailman3.org/accounts/login/?next=/mailman3/lists/ have some providers set up, we can test what the flow is there or enable it on lists.wmcloud.org.

https://docs.mailman3.org/en/latest/config-web.html#configure-social-login 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 https://github.com/tgr/django-allauth/commit/c4c50ccfd2fc9fb50ba028914b0b0c03790338db

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:

SOCIALACCOUNT_PROVIDERS = {
    'wikimedia': {
        'DOMAIN': 'meta.wikimedia.org',
        '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 https://polymorphic.lists.wmcloud.org/admin/socialaccount/socialapp/, 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 b@provider.org and is pending verification, user B who actually owns b@provider.org 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.

In T249678#7105723, @Legoktm wrote:

• 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.

https://github.com/tgr/django-allauth/commit/c4faf77d8a3515c1ea9d272dc5d5cd797782d8c0 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 https://gitlab.com/mailman/django-mailman3/-/tree/master/django_mailman3/static/django-mailman3/img/login, 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?

In T249678#7106765, @Legoktm wrote:

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?

In T249678#7107094, @Tgr wrote:

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.

Upstream patch is pennersr/django-allauth#2873.

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).

In T249678#7504117, @Tgr wrote:

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).

Looks like this was released in 0.46 on 2021-11-15 <ref>https://django-allauth.readthedocs.io/en/latest/release-notes/2021.html</ref>