Subscription request cannot be moderated: 404 Not Found
For one of our mailinglists we also have a problem with accepting a subscription request. When Clicking "Accept", we get a 404 Not found error. See the attached screenshot. Is there a way to solve this? Best Regards,Eric
Has anyone an idea why the described issue happens? The subscription request is shown in the pending approval subscription requests, but when accepting it a 404 Not found error is given. Best Regards,Eric On Saturday, January 9, 2021, 02:40:19 PM GMT+1, Eric Broens via Mailman-users <mailman-users@mailman3.org> wrote:
For one of our mailinglists we also have a problem with accepting a subscription request. When Clicking "Accept", we get a 404 Not found error. See the attached screenshot. Is there a way to solve this? Best Regards,Eric
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
On 1/9/21 5:39 AM, Eric Broens via Mailman-users wrote:
For one of our mailinglists we also have a problem with accepting a subscription request. When Clicking "Accept", we get a 404 Not found error. See the attached screenshot. Is there a way to solve this?
Content filtering removed your screenshot so we can't see it. What is the URL that gives the 404? How does this compare to the URL of the held message view?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark, The link that shows the subscription request pending approval is as follows: 'https://<host_url>/postorius/lists/<listname>.<domain>/subscription_requests'
The link behind the accept button is as follows. 'https://<host_url>/postorius/lists/<listname>.<domain>/handle_subscription_request/4d6b4b11266c7332684c5a492eb3f92c531f761b/accept'
I have checked if there is already a subscription with that email address, but that's not the case. Best Regards,Eric On Thursday, January 14, 2021, 08:43:54 PM GMT+1, Mark Sapiro <mark@msapiro.net> wrote:
On 1/9/21 5:39 AM, Eric Broens via Mailman-users wrote:
For one of our mailinglists we also have a problem with accepting a subscription request. When Clicking "Accept", we get a 404 Not found error. See the attached screenshot. Is there a way to solve this?
Content filtering removed your screenshot so we can't see it. What is the URL that gives the 404? How does this compare to the URL of the held message view?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
On 1/14/21 3:43 PM, Eric Broens via Mailman-users wrote:
Hi Mark, The link that shows the subscription request pending approval is as follows: 'https://<host_url>/postorius/lists/<listname>.<domain>/subscription_requests'
The link behind the accept button is as follows. 'https://<host_url>/postorius/lists/<listname>.<domain>/handle_subscription_request/4d6b4b11266c7332684c5a492eb3f92c531f761b/accept'
I have checked if there is already a subscription with that email address, but that's not the case.
I don't know why that would 404 unless the token 4d6b4b11266c7332684c5a492eb3f92c531f761b didn't exist, but since it came from a "current" view, it should be good.
I have seen occasional issues where two moderators attempt to handle the same request in close succession - i.e. both get the pending request and try to handle it and the second fails because the request is gone, but that appears not to be the case here.
You might check the web server logs, the Django log and Mailman's logs to see if there is any more of a clue.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark, I can't find any log entry which indicate a problem with this subscription request. The _request table does not contain a request for the specific mailinglist, but I am not sure if subscription requests are included in this table. The token is found in the pended table:
+-----+------------------------------------------+---------------------+ | id | token | expiration_date | +-----+------------------------------------------+---------------------+ | 115 | 4d6b4b11266c7332684c5a492eb3f92c531f761b | 2031-01-04 16:17:38 | +-----+------------------------------------------+---------------------+
These are the relevant entries in the pendedkeyvalue table: +------+--------------+-------------------------------------+-----------+ | id | key | value | pended_id | +------+--------------+-------------------------------------+-----------+ | 1130 | type | subscription | 115 | | 1131 | list_id | "********************" | 115 | | 1132 | email | "***********************@*********" | 115 | | 1133 | display_name | "" | 115 | | 1134 | when | "2021-01-06T16:17:38" | 115 | | 1135 | token_owner | "moderator" | 115 | +------+--------------+-------------------------------------+-----------+
Can I workaround this problem for this specific subscriber by adding entries in the _request table, and if so what do I need to add? Thanks in advance, Eric
On Friday, January 15, 2021, 11:42:47 PM GMT+1, Mark Sapiro <mark@msapiro.net> wrote: On 1/14/21 3:43 PM, Eric Broens via Mailman-users wrote:
Hi Mark, The link that shows the subscription request pending approval is as follows: 'https://<host_url>/postorius/lists/<listname>.<domain>/subscription_requests'
The link behind the accept button is as follows. 'https://<host_url>/postorius/lists/<listname>.<domain>/handle_subscription_request/4d6b4b11266c7332684c5a492eb3f92c531f761b/accept'
I have checked if there is already a subscription with that email address, but that's not the case.
I don't know why that would 404 unless the token 4d6b4b11266c7332684c5a492eb3f92c531f761b didn't exist, but since it came from a "current" view, it should be good.
I have seen occasional issues where two moderators attempt to handle the same request in close succession - i.e. both get the pending request and try to handle it and the second fails because the request is gone, but that appears not to be the case here.
You might check the web server logs, the Django log and Mailman's logs to see if there is any more of a clue.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
On 1/16/21 7:49 AM, Eric Broens via Mailman-users wrote:
Hi Mark, I can't find any log entry which indicate a problem with this subscription request. The _request table does not contain a request for the specific mailinglist, but I am not sure if subscription requests are included in this table.
It is unclear and confusing, but the requests are not in the _request table. See <https://gitlab.com/mailman/mailman/-/issues/768#note_415536043>. So this is normal.
The token is found in the pended table:
+-----+------------------------------------------+---------------------+ | id | token | expiration_date | +-----+------------------------------------------+---------------------+ | 115 | 4d6b4b11266c7332684c5a492eb3f92c531f761b | 2031-01-04 16:17:38 | +-----+------------------------------------------+---------------------+
These are the relevant entries in the pendedkeyvalue table: +------+--------------+-------------------------------------+-----------+ | id | key | value | pended_id | +------+--------------+-------------------------------------+-----------+ | 1130 | type | subscription | 115 | | 1131 | list_id | "********************" | 115 | | 1132 | email | "***********************@*********" | 115 | | 1133 | display_name | "" | 115 | | 1134 | when | "2021-01-06T16:17:38" | 115 | | 1135 | token_owner | "moderator" | 115 | +------+--------------+-------------------------------------+-----------+
Can I workaround this problem for this specific subscriber by adding entries in the _request table, and if so what do I need to add?
Adding to the _request table won't help. Try confirming by emailing
listname-confirm+4d6b4b11266c7332684c5a492eb3f92c531f761b@list.domain
You could also try confirming via mailman shell
ISubscriptionManager(m).confirm('4d6b4b11266c7332684c5a492eb3f92c531f761b') Traceback (most recent call last): File "<console>", line 1, in <module> File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman-3.3.3b1-py3.7.egg/mailman/app/subscriptions.py",
mailman shell -l list.example.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the list.example.com mailing list line 570, in confirm raise LookupError LookupError
In my case, I get the LookupError because the token doesn't exist, but I think it should work for you.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark, Unfortunately the provided options didn't work out either:
Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the ************* mailing list
ISubscriptionManager(m).confirm('4d6b4b11266c7332684c5a492eb3f92c531f761b') Traceback (most recent call last): File "<console>", line 1, in <module> File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.py", line 578, in confirm workflow.restore() File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", line 142, in restore raise LookupError(self.token) LookupError: 4d6b4b11266c7332684c5a492eb3f92c531f761b
I noticed that the mail address was also listed as a non-member. After deleting it there, I could not accept the subscription either. Next, I have rejected the subscription and added it using the mass subscription option in the WebUI.
I'll monitor if such cases will happen again.
Thanks,Eric On Saturday, January 16, 2021, 06:05:19 PM GMT+1, Mark Sapiro <mark@msapiro.net> wrote:
On 1/16/21 7:49 AM, Eric Broens via Mailman-users wrote:
Hi Mark, I can't find any log entry which indicate a problem with this subscription request. The _request table does not contain a request for the specific mailinglist, but I am not sure if subscription requests are included in this table.
It is unclear and confusing, but the requests are not in the _request table. See <https://gitlab.com/mailman/mailman/-/issues/768#note_415536043>. So this is normal.
The token is found in the pended table:
+-----+------------------------------------------+---------------------+ | id | token | expiration_date | +-----+------------------------------------------+---------------------+ | 115 | 4d6b4b11266c7332684c5a492eb3f92c531f761b | 2031-01-04 16:17:38 | +-----+------------------------------------------+---------------------+
These are the relevant entries in the pendedkeyvalue table: +------+--------------+-------------------------------------+-----------+ | id | key | value | pended_id | +------+--------------+-------------------------------------+-----------+ | 1130 | type | subscription | 115 | | 1131 | list_id | "********************" | 115 | | 1132 | email | "***********************@*********" | 115 | | 1133 | display_name | "" | 115 | | 1134 | when | "2021-01-06T16:17:38" | 115 | | 1135 | token_owner | "moderator" | 115 | +------+--------------+-------------------------------------+-----------+
Can I workaround this problem for this specific subscriber by adding entries in the _request table, and if so what do I need to add?
Adding to the _request table won't help. Try confirming by emailing
listname-confirm+4d6b4b11266c7332684c5a492eb3f92c531f761b@list.domain
You could also try confirming via mailman shell
ISubscriptionManager(m).confirm('4d6b4b11266c7332684c5a492eb3f92c531f761b') Traceback (most recent call last): File "<console>", line 1, in <module> File "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman-3.3.3b1-py3.7.egg/mailman/app/subscriptions.py",
mailman shell -l list.example.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the list.example.com mailing list line 570, in confirm raise LookupError LookupError
In my case, I get the LookupError because the token doesn't exist, but I think it should work for you.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
On 1/16/21 9:46 AM, Eric Broens via Mailman-users wrote:
Hi Mark, Unfortunately the provided options didn't work out either:
Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the ************* mailing list
ISubscriptionManager(m).confirm('4d6b4b11266c7332684c5a492eb3f92c531f761b') Traceback (most recent call last): File "<console>", line 1, in <module> File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.py", line 578, in confirm workflow.restore() File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", line 142, in restore raise LookupError(self.token) LookupError: 4d6b4b11266c7332684c5a492eb3f92c531f761b
It appears that although the token was in the pended table, it wasn't in the workflowstate table. I have no clue how this happened.
I noticed that the mail address was also listed as a non-member. After deleting it there, I could not accept the subscription either. Next, I have rejected the subscription and added it using the mass subscription option in the WebUI.
I'll monitor if such cases will happen again.
Hopefully it won't happen again, but at least you have a workaround.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Eric Broens -
Mark Sapiro