Creating users via RestAPI / User-Management - a bunch of questions
Dear Mark and companions,
somehow I can not cope with the user management... (I am running a venv-installation, latest stable versions)
I read this manual: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/u... and played with the RestAPI calls...
I know about the fine grained differences between user and member, admin/owner, superuser... and about the two user databases in PostgreSQL and Django-Framework.
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. (And this user is visible on the User-URL (https://example.com/mailman3/users)) Even when I (via WebUI) set the user as "approved" this user is not able to log in... I assume this restriction is in accordance to the fact that there is not equivalent 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)
When I create the user using the WebUI (https://example.com/accounts/signup/?next=/mailman3/lists/) the new user is created in the right (complete) way...appearing in the PostgreSQL database and as a user in Django. How is this sync between the two databases realized? (The Django user also has the correct status (no staff status / no superuser status / just active status) how is this realized?)
As I am not very familiar with python programming (I know Perl/Java/C++ and have an (maybe outdated) concept of OOP), is there a quick way to implement this kind of sync by copying the register logic from mailman's python action script for registering?
Other questions: Will there be a create_admin_user-script that is callable via CLI (like createsuperuser or create_list)? (This script ought create a user in PostgreSQL and as Django user)
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?)
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? 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... ;-))
Thank you for some clarifying hints... :-)
Chris
On 6/20/25 06:39, Christian Schneider wrote:
Dear Mark and companions,
somehow I can not cope with the user management... (I am running a venv-installation, latest stable versions)
I read this manual: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/u... and played with the RestAPI calls...
I know about the fine grained differences between user and member, admin/owner, superuser... and about the two user databases in PostgreSQL and Django-Framework.
I'm not sure what distinction you are making between PostgreSQL and
Django-Framework. There are two separate and distinct users, Django
users and Mailman core users. Information about both is in the
PostgreSQL database. Django users are in the auth_user table and
Mailman core users are in the user table, both in the public schema,
although if you split the data into a mailman database and a
mailmanweb database the auth_user table is in mailmanweb and the
user table is in mailman.
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. (And this user is visible on the User-URL (https://example.com/mailman3/users)) Even when I (via WebUI) set the user as "approved" this user is not able to log in... I assume this restriction is in accordance to the fact that there is not equivalent 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.
When I create the user using the WebUI (https://example.com/accounts/signup/?next=/mailman3/lists/) the new user is created in the right (complete) way...appearing in the PostgreSQL database and as a user in Django. How is this sync between the two databases realized?
I'm still looking into that, but it isn't the creation of the Django user per se that creates the Mailman user. The process has multiple steps.
Sign-up for an account. This creates the Django user and sends an address confirmation email.
Click the link in the confirmation email. This takes you to a page with a
Confirmbutton to confirm the email address.Click the confirm button.
It is not until step 3) that the Mailman user and address records are created.
(The Django user also has the correct status (no staff status / no superuser status / just active status) how is this realized?)
Presumably by the sign-up process not setting staff status and superuser status.
As I am not very familiar with python programming (I know Perl/Java/C++ and have an (maybe outdated) concept of OOP), is there a quick way to implement this kind of sync by copying the register logic from mailman's python action script for registering?
I think it must be django-mailman3 that's doing this, but I haven't been able to see how so far. django-mailman3 does override the template for the /accounts/confirm-email page, but this is only to include styling.
Other questions: Will there be a create_admin_user-script that is callable via CLI (like createsuperuser or create_list)? (This script ought create a user in PostgreSQL and as Django user)
No plans. There are mailman addmembers and mailman admins commands
to add members or admins to a list. Adding an owner or moderator to a
list via mailman admins will also create a Mailman user for that
person if there isn't one already, but it won't create a Django user.
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..
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? 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.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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
Hello Mark, hello Stephen,
thank you very much for your very detailed explanations concerning the user management! I appreciate it very much!!!
@Mark: Your assumption is right:
I'm not sure what distinction you are making between PostgreSQL and Django-Framework. There are two separate and distinct users, Django users and Mailman core users. Information about both is in the PostgreSQL database. Django users are in the auth_user table and Mailman core users are in the user table, both in the public schema, although if you split the data into a mailman database and a mailmanweb database the auth_user table is in mailmanweb and the user table is in mailman. I have two databases, a mailman db and a mailman-web db with the two user tables (user and auth_user). I did not realize that the django users are stored in the auth_user table of the mailman-web db. So both "user databases" are in ProstgreSQL dbms...mailman core and django. I should refer to them as mailman core users and django users...that is clear to me now... :-)
@Stephen: your substantial remarks on social account providers are very helpful:
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...).
Now I know I have to connect our IdP first! This step should provide access to the WebUI/django for all users reigned by our IdP. In a second step I can set up according (selected) mailman core users and in a third step I assign these users to a list as admin/owner or member.(*)
(*) Maybe there needs to be adaptions to the status flags (is_superuser, is_staff, is_active) for the django users between step one and two - i will have to see for that...
Thank you again for your helpful input!
Chris
participants (3)
-
Christian Schneider -
Mark Sapiro -
Stephen J. Turnbull