On Mar 20, 2021, at 6:22 AM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Core implementation details, so I beinging this here from Mailman Users @ mailman3.org.
Abhilash Raj writes:
I have started working on designing a User management page2 in Core which should make it easy for superuser to manage several things about a User, including the ones that don’t have an account in Postorius to manage their own.
I don't understand this design with a "page in Core”.
Typo :( Page in Postorius is what I meant to say.
I was thinking about this kind of problem, and tentatively came to the conclusion that any reference to something that can be resolved to a User should generate a Django account for that User in Postorius or HyperKitty.
Is that necessarily required? Every user in Django has a corresponding user in Core, but the converse isn’t true and I am not sure if that is even required.
The purpose of a Django account is to manage my own email addresses and subscriptions. An admin can manage a Core User that does or doesn’t have a Django account. The only thing that changes is what they can do with that user. See below for my thoughts on the actions an admin would be able to perform.
The high level design of that user management page is that it will provide a list of Users straight from Core. When you go to an individual User’s management page,
You will be able to see:
- Does the user have a Django account?
- All Subscriptions for the User
- All addresses of the User
You will be able to perform following actions:
- Add or remove a user’s address
- Verify or un-verify an address
- Set any address as primary for the user
- Update display name of the user
- Update address on any of the subscriptions
If the User has a Django account, you also be able to:
- Manage the User’s password *if* they are using password for login and not social auth.
- Reset “social login” for the user?
- View some of the RO info about the Django User model, like last login, superuser status or few other attributes that we feel is useful for admin in any situation.
What I am on fence about:
- Provide a full blown preferences menu to the admin for that user. This will also make the UI extremely complex to see and implement.
Authorization to use that account would still require authentication via the usual email verification dance, or some level of admin privilege.
The thing is that emails that have not been added to a User are unique. They will be the only Address attached to User created to manage them until authenticated, and transitively the only address attached to an automatically-created Django account (since those are 1-1 with core Users if they exist AFAIK).
In Core, when a new address (email1) comes in, a Mailman User(user1) is created for it.
But, when you have an account in Django with a different email (email2) and a different Mailman user (user2) and you add a second email (email1) to your account and are able to prove ownership by verifying the address, Django will ask Core to add that second address (email1) to your Mailman user (user2) and absorb “user1”. This process is already implemented.
However, if two Django accounts are created for “user1” and “user2” then situation becomes more tricky and currently we don’t have a way to resolve that short of delete one of the accounts and add the addresses to other account.
What's missing here is the ability to merge core Users and their corresponding Django accounts. Doing this with nothing more than the usual email verification dance is not *obviously* provably secure to me, so we need to be careful, but I think it probably will turn out to be as secure as you can get. It seems to me that User merging is the most pressing problem of this kind. (At least, it affects me on a couple of list hosts, as well as on GitHub and GitLab.)
I'll take a look tomorrow or early next week.
It is far from actually usable, so you can actually skip it for now ;-) I can announce it when it is in semi-usable state.
-- thanks, Abhilash Raj (maxking)