Cannot request password reset: "The e-mail address is not assigned to any user account"
I have set up Mailman Core Version GNU Mailman 3.3.5 with Mailman Core API Version 3.1 (Python 3.8.10) using the version 0.40 Docker images. I was able to get things set up and tested by requesting a password reset for the MAILMAN_ADMIN_USER specified in the docker.yaml.
Using the web API, I have created several mailing lists and I have added members to these lists also using the web API (most relevant: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/m...), specifying that each member is already pre_verified, pre_confirmed, and pre_approved. The lists themselves seem to be working fine.
The problem is when our staff try to reset their password (through Postorious) to get access and do moderation tasks. The error message "The e-mail address is not assigned to any user account" displays no matter which email address I enter (except the one from MAILMAN_ADMIN_USER which works). Using the MAILMAN_ADMIN_USER I can sign in, view the list of all the users, see their Addresses (one each) and Subscriptions, but even after toggling off "Verified" for the staff email address, clicking Update, then turning Verified back on and updating again, I still can't reset the password for that email address from the "forgot pasword" screen. Even tried adding that email address as another list owner.
I have not made any API calls specific to adding users because the API documentation says, "Since her email address is not yet known to Mailman, a user is created for her." This does seem to have happened; GET 127.0.0.1:8001/3.1/users does show everyone's display name and unique user_id strings.
I have tried using the API to PATCH a temporary password to the user but that didn't fix the inability to reset. The encrypted password does show in the /users/ data reported by the API (where previously there had been none), and a POST to users/<user_id>/login with that password return the 204 status shown to indicate success (instead of 403)... but I can't log in using Postorious with this user's email address and password. I also tried PATCHing the cleartext_password to /users/<email_address> and wasn't able to login or reset after that either.
According to the API, each of the users -- webadmin where I can reset the password and staff where I can't -- does have a single address. (In the following, I redacted the API username and password ; changed email addresses, and IP address. And the display name, but left the timestamps and user_ids )
$ curl --user xxxx:xxxx "127.0.0.1:8001/3.1/users/29bf1eef2ee14f39a7990757544f11a9/addresses" {"start": 0, "total_size": 1, "entries": [{"email": "webadmin@example.com", "original_email": "webadmin@example.com", "registered_on": "2021-11-25T04:20:33.408184", "self_link": "http://1.2.3.4:8001/3.1/addresses/webadmin@example.com", "verified_on": "2021-11-25T04:20:33.960577", "user": "http://1.2.3.4:8001/3.1/users/29bf1eef2ee14f39a7990757544f11a9", "http_etag": "\"394c07148f3fd0479cc582358b63b919fd988e36\""}], "http_etag": "\"a6621373598d299c32aa946fef7e32167d796bf3\""}
$ curl --user xxxx:xxxx "127.0.0.1:8001/3.1/users/73235926306843ccb41f288d0464240a/addresses" {"start": 0, "total_size": 1, "entries": [{"email": "staff@example.com", "original_email": "staff@example.com", "registered_on": "2021-12-15T02:25:24.055741", "self_link": "http://1.2.3.4:8001/3.1/addresses/staff@example.com", "display_name": "Staff Member", "verified_on": "2021-12-15T02:40:04.941153", "user": "http://1.2.3.4:8001/3.1/users/73235926306843ccb41f288d0464240a", "http_etag": "\"f24ba7ca9d71a7f814dc41d70c48ce947c1324be\""}], "http_etag": "\"e8d5b9f3ce0abbc7bbf51c03c69367f82679f93e\""}
I am probably missing something, but this second query seems to confirm that the address "staff@example.com" is assigned to the user 73235926306843ccb41f288d0464240a and so shouldn't I should be able to request a password reset for "staff@example.com"?
I've tried tailing all the log files I can find while attempting the reset and am not seeing any error messages, but I don't know exactly where to look.
Thank you for any suggestions for what to try next!
Dave
On 1/26/22 22:21, dave--- via Mailman-users wrote:
Using the web API, I have created several mailing lists and I have added members to these lists also using the web API (most relevant: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/m...), specifying that each member is already pre_verified, pre_confirmed, and pre_approved. The lists themselves seem to be working fine.
The problem is when our staff try to reset their password (through Postorious) to get access and do moderation tasks. The error message "The e-mail address is not assigned to any user account" displays no matter which email address I enter (except the one from MAILMAN_ADMIN_USER which works).
The password reset is for a Django user, which is distinct from a
Mailman user. The users you added via the web API are Mailman users, but
in order to access their lists via the web UI they have to sign up to
create a Django account.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
The concept of a Django user sounds like the big thing I was missing. Thank you; I believe I have resolved the immediate need. I'm thinking, then, that if I want to be able to programmatically create the Django users in parallel with our Mailman users (I don't want to have registration open to the world), I'm going to have to do some coding... either create some sort of Postorius API or perhaps better would be to make a social / OAuth plug-in that will use our existing membership site. (Once I get stuck on that, I'll switch to the developer list.) Thanks again.
On 1/28/22 00:58, dave--- via Mailman-users wrote:
The concept of a Django user sounds like the big thing I was missing
now that is something that i wanted to get clarifified in the context of my "getting all registered users" question as well.
i'm afraid i still do not fully understand which types of "users" there are.
afaics, there are three different types:
- django users this is what get's listed under <https://lists.mailman3.org/admin/auth/user/>
- mailman accounts this is what is created when you visit <https://lists.mailman3.org/accounts/signup/>
- email addresses this is what is created when i subscribe to a list *without* having an account. e.g. via the "Subscribe" button on <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>
afaiu, (multiple) "email addresses" can be associated with a single "mailman account" (but this is strictly optional). if an "email address" is first used to subscribe to a list without a mailman account, and later a mailman account is created with that very email address, they get automatically associated. a single "email address" cannot be associated with more than one "mailman accounts". i think i got this one right (as it seems pretty straightforward).
what i don't fully grasp yet is the relation between "django users" and "mailman accounts". intuitively, i would have thought that they are identical.
now mark wrote:
a Django user, which is distinct from a Mailman user. The users you added via the web API are Mailman users, but in order to access their lists via the web UI they have to
sign upto create a Django account.
that seems to indicate, that a "django user" is a (strict) superset of a "mailman account". you (as admin) can create "mailman accounts" via the web API¹, but they are only expanded to "mailman accounts" if you (as user) go through the "Sign Up" process. otoh, if you create an initial "django user" by signing up, you automatically create a "mailman account".
so are the two distinct concepts that are just associated via some common property (e.g. the email address), or is there some intrinsic relationship between the two (e.g. parent-child inheritance relationship)?
so my recent experiment (comparing the output of
<https://lists.example.com/admin/auth/user/> with that of [u for u in getUtility(IUserManager).users]) indicates that they are indeed
distinct objects that *can* be associated with each other.
could you please clarify this?
so why am i interested in this? "users" are often associated with some capabilities/powers (which can of course be exploited) it makes me rather uneasy to not understand the core permission model.
also (as indicated in my original mail), i'm running mailman3-3.2.1, a rather outdated version, on Debian/buster (an outdated Debian release as well). i would like to upgrade rather sooner than later. otoh, just recently there was a thread on how upgrading a Debian-based mailman3 installation (from buster to bullseye, just like what i plan to do) can go wrong. if things do go wrong, i would rather like to understand where they go wrong, so i'd like to prepare myself :-)
fmdsf IOhannes
¹ totally OT, but thanks: finally somebody who calls it "web API" rather than just "API" as if there was no non-RESTful world.
On 1/28/22 00:41, IOhannes m zmölnig wrote:
i'm afraid i still do not fully understand which types of "users" there are.
afaics, there are three different types:
- django users this is what get's listed under <https://lists.mailman3.org/admin/auth/user/>
Correct.
- mailman accounts this is what is created when you visit <https://lists.mailman3.org/accounts/signup/>
No. That creates a Django user, not a Mailman user. What you think of as a Mailman account is actually a Django account.
- email addresses this is what is created when i subscribe to a list *without* having an account. e.g. via the "Subscribe" button on <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>
Mailman core has users and addresses. A user has one or more associated
addresses. When you subscribe to a list without having an account in
that way, or via email to list-join or list-subscribe or by being mass
subscribed by the list admin or by being imported by mailman import21,
assuming you are previously unknown, this creates a Mailman user with an
associated address and subscribes the user or address.
Each user has a primary address and zero or more additional linked addresses. The user can be subscribed to a list as a user in which case, delivery if any is to the user's primary address, or can be subscribed as an address.
afaiu, (multiple) "email addresses" can be associated with a single "mailman account" (but this is strictly optional).
Yes, see above.
if an "email address" is first used to subscribe to a list without a mailman account, and later a mailman account is created with that very email address, they get automatically associated. a single "email address" cannot be associated with more than one "mailman accounts".
Based on the above, your "mailman accounts" are actually Django accounts. With that in mind, the above is correct, but there is no real link between Mailman users and Django users. When you are logged in to the web UI you are logged in as a Django user, and Postorius and HyperKitty know that user's email address and can therefore know if it is a list member and know what address to subscribe or unsubscribe as requested.
i think i got this one right (as it seems pretty straightforward).
what i don't fully grasp yet is the relation between "django users" and "mailman accounts".
As I have said, what you are calling a mailman account is a Django user and not a Mailman user.
intuitively, i would have thought that they are identical.
They are, but they are not Mailman core users.
now mark wrote:
a Django user, which is distinct from a Mailman user. The users you added via the web API are Mailman users, but in order to access their lists via the web UI they have to
sign upto create a Django account.that seems to indicate, that a "django user" is a (strict) superset of a "mailman account".
No. A Django user is the same thing as what you call a mailman account. A Mailman core user is a separate thing entirely.
you (as admin) can create "mailman accounts" via the web API¹, but they are only expanded to "mailman accounts" if you (as user) go through the "Sign Up" process.
No. An admin can create Mailman users via the Postorius UI. A Django superuser can also create Django users through the Django admin UI.
otoh, if you create an initial "django user" by signing up, you automatically create a "mailman account".
Because they are the same thing. When you go to the Sign-up link on a Postorius or Hyperkitty page you go to https://example.com/accounts/signup/, and that's Django, not Mailman.
so are the two distinct concepts that are just associated via some common property (e.g. the email address), or is there some intrinsic relationship between the two (e.g. parent-child inheritance relationship)?
They are distinct. Django users have email addresses and Mailman users have email addresses and they can be associated in that way. There is no other link.
so my recent experiment (comparing the output of <https://lists.example.com/admin/auth/user/> with that of
[u for u in getUtility(IUserManager).users]) indicates that they are indeed distinct objects that *can* be associated with each other.could you please clarify this?
I hope I have.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
dave＠aasv.org -
IOhannes m zmölnig -
Mark Sapiro