Mark Sapiro writes:
On 6/20/25 06:39, Christian Schneider wrote:
What I stumble upon is the RestAPI calls to create a "working" user (with the ability to login via WebUI). When I follow the manual (from the url above) I create a user (including password) that appears in the PostgreSQL database.
If you mean you create a User with password via the REST API, this password is useless. It is not visible to the Django user management code, and there is no way for a user to log in to Mailman via the REST API -- the only one who can log in via REST is the superuser.
Even when I (via WebUI) set the user as "approved" this user is not able to log in...
I'm not sure how this works, exactly, but I think what you need to do via REST API is
- Create the User.
- Give it an email Address (this probably is automatic, I don't know if you can create a "bare" user without an email address at all).
- (probably optional) Set that address as verified.
Then through the Postorius interface you should be able to look up that user via the email address. That should create a Django user if one doesn't exist for that email address. I don't recall if Postorius allows you to set the user's password. You may have to go via the Django admin interface (the /admin location which is sibling to /mailman3 and /archives). I'm not sure how to find that user (I don't know what the user's account name in Django is, hopefully you can look up the user via the email).
I assume this restriction is in accordance to the fact that there is not equivalent Django user.
I don't think there can be a Postorius access to a Mailman user without a Django user.
(There was a mail in the archive of the MM3 user group...stating that one has to use the Django RestAPI to create the appropriate user)
The above is correct. The Mailman REST API only deals with Mailman core. Mailman core knows nothing about Django.
Right, if you want to do the whole thing in a script you'll have to access Django.
How will a social account provider (like oidc) linkage (in Django) fit in this concept? Will oidc-accounts be copied to the Django's user database (or PostgreSQL db) or is it an on-the-fly check against the oidc-provider? (I assume second option) What are the status-flags (staff status/superuser status/active status) of the linked oidc-accounts? (Can I specify the status flags?)
I don't offhand know the answers to that, but I think logging in via a social account provider creates a Django user..
I can't speak for generic social accounts, but it definitely did that for a Shibboleth-based SSO setup. Just pass the login credentials provided by Shibboleth through to the social account stuff (verrrry carefully :-), and everything just works.
Social auth gets the bare minimum information from the idP as far as I know (didn't look into it carefully). At least in my case all we got from Shibboleth was a display name (the personal name) and an email address (not even an verifiable auth token, they trusted their network that much). Users could set passwords but they didn't work (Django could only be accessed by users logged in to the network, and if you logged out, the request triggered by the redirect back to the login page would log you right back in again! Freaky...).
A conceptual thought:
When "user1" (with email user1@example.com) is known to django via oidc linkage and I create "user1" (also with email user1@example.com) via RestAPI calls (following the url https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/u...) do I have a "complete" user then?
That depends on how the social auth is set up. Most likely the account is linked to the email, Django trusts that email if validated by the idP, and it will create a Django user to manage it if one doesn't already exist. If you are accessing Postorius or HyperKitty, that app will trust the email because it trusts Django, and it will create a Mailman user as Mark described if one doesn't already exist. (I don't think the Django and Mailman user-ids need to match, even.)
I'm not sure what happens if you create the Mailman user and assign it that email address independently of creating the Django user. I think it should "just work" to log in via Django as long as the idP vouches that the email is authentic.
Note that there's one glitch remaining -- I'm pretty sure[1] that if you have an existing Mailman user, and the email address is in the unconfirmed state in Mailman, you'll have to confirm it to subscribe to lists and probably to do any other work with that user logged in by that address. You can do that via "one-time key" email dance, or via the Mailman REST API though. (It may be possible to do that via the Django admin API as well, but obviously you can't do that with Postorius, or anybody could claim any address.)
Short version:
I mean a user who is able to login and who can be assigned to a list as admin (e.g.) (In this case I would not have to care about the Django user database... ;-))
If the user can log in to the web UI with an associated email address, if that address is an admin of a list, the logged in user can admin the list.
Footnotes: [1] Actually, I'm not sure at all but you *should* have to confirm!
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan