Andreas Barth writes:
To make it more complex (perhaps?), I'd like to switch django to use the single sign on-system, which means: mail adresses and user accounts are managed elsewhere, and djano / mailman / whatever component consumes accounts (and verified mail adresse) from the central account store.
Django *is* our single-sign-on system, and Mailman core *is* our central account store. That's why it's possible to mix and match Mailman core with other UI applications. This has been proved in practice by at least one commercial service.
That is, we don't do *any* authentication in Mailman core. And because authenticating general Internet connections is *hard*, we want to keep it that way![1] ;-) The single exception is the mail address verification dance, which is an extremely simple protocol with a well-known threat model that nobody can do anything about (somebody who can read your mail).[2]
So we delegate authentication and credentials management to Django, which already knows how to do passwords, OAuth and friends, and probably multifactor, too. That's *all* that the Django account functionality does for Postorius.[3] All the other user and admin information that Postorius exposes are ultimately backed by queries to Mailman core's REST API, not by Django's internal database.
This subthread is 100% about how to initialize the Mailman core user record in a way more consistent with user expectations. The other, closely related subthread is about presenting tables of subscriber data for multiple subscriptions, instead of requiring people to visit per-subscription pages. There's no need to change the division of labor between core and Postorius to implement either.
Steve
Footnotes: [1] We probably can't, in the long run. People definitely want Mailman systems distributed across multiple hosts, and there are limits to how well that can work with all the hosts behind a firewall. That implies authenticating connections to the REST API endpoints.
[2] Technically, in theory we could encrypt the verification email in case there's a miscreant-in-the-middle who can read plain text, but then we've got a key distribution problem and a user education problem. Encryption is like regexps but worse: whenever you have a problem and you adopt encryption as the answer, now you have *three* problems! :-P
[3] I'm not sure about HyperKitty. Mailman core doesn't know or care about web preferences, so I suppose HyperKitty has to store them somewhere.