I'm on to the next layer of the onion for my migration. Now I have admin/moderator requests to handle. When I click the appropriate radio buttons and click the submit button, nothing happens. The page refreshes but the requests remain. TIA.
On 01/27/2015 05:30 AM, Dennis Putnam wrote:
I'm on to the next layer of the onion for my migration. Now I have admin/moderator requests to handle. When I click the appropriate radio buttons and click the submit button, nothing happens. The page refreshes but the requests remain. TIA.
If that doesn't help, look at the source of the admindb page in your browser and verify that the ACTION= attribute in the FORM tag is going where you want.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 01/27/2015 11:06 AM, Mark Sapiro wrote:
That's a bit too looong...
It works, but this one is a bit better
<http://wiki.list.org/DOC/4.45 The admin web interface is not saving my changes and may or may not ask me to re-enter my password -- what is wrong?>
We need a way to generate short URLs for this wiki. The old Confluence tiny URLs work through a remapping process, but we don't yet have a way to generate new ones. It's on my list ...
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark,
They both worked for me. In any case, yes I did all those things in the faq. However, all the requests have magically disappeared. I am thinking it may be a caching problem as they were gone after I logged off and back on. As long as I kept going to that page without a new login request, they stayed on the page. Shouldn't there have at least been an error when it tried to process requests that no longer existed?
On 1/27/2015 2:14 PM, Mark Sapiro wrote:
On 01/27/2015 11:06 AM, Mark Sapiro wrote:
See the FAQ at <http://wiki.list.org/DOC/4.45%20The%20admin%20web%20interface%20is%20not%20saving%20my%20changes%20and%20may%20or%20may%20not%20ask%20me%20to%20re-enter%20my%20password%20--%20what%20is%20wrong?action=show&redirect=DOC%2F4.45+The+admin+web+interface+is+not+saving+my+changes+and+keeps+asking+me+to+re-enter+my+password+--+what+is+wrong%3F> That's a bit too looong...
It works, but this one is a bit better
<http://wiki.list.org/DOC/4.45 The admin web interface is not saving my changes and may or may not ask me to re-enter my password -- what is wrong?>
We need a way to generate short URLs for this wiki. The old Confluence tiny URLs work through a remapping process, but we don't yet have a way to generate new ones. It's on my list ...
Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/dap1%40bellsouth.net
On 01/27/2015 11:23 AM, Dennis Putnam wrote:
Hi Mark,
They both worked for me. In any case, yes I did all those things in the faq. However, all the requests have magically disappeared. I am thinking it may be a caching problem as they were gone after I logged off and back on. As long as I kept going to that page without a new login request, they stayed on the page. Shouldn't there have at least been an error when it tried to process requests that no longer existed?
No. The admindb CGI assumes that another moderator (or this moderator in another browser tab or ...) handled that message and ignores the fact that it's 'gone'.
It's hard to understand how caching would return a cached page in lieu of the page sent by the CGI, but unless you can actually figure out how to repeat this, we won't know what happened.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 1/27/2015 2:23 PM, Dennis Putnam wrote:
Hi Mark,
They both worked for me. In any case, yes I did all those things in the faq. However, all the requests have magically disappeared. I am thinking it may be a caching problem as they were gone after I logged off and back on. As long as I kept going to that page without a new login request, they stayed on the page. Shouldn't there have at least been an error when it tried to process requests that no longer existed?
On 1/27/2015 2:14 PM, Mark Sapiro wrote:
On 01/27/2015 11:06 AM, Mark Sapiro wrote:
See the FAQ at <http://wiki.list.org/DOC/4.45%20The%20admin%20web%20interface%20is%20not%20saving%20my%20changes%20and%20may%20or%20may%20not%20ask%20me%20to%20re-enter%20my%20password%20--%20what%20is%20wrong?action=show&redirect=DOC%2F4.45+The+admin+web+interface+is+not+saving+my+changes+and+keeps+asking+me+to+re-enter+my+password+--+what+is+wrong%3F> That's a bit too looong...
It works, but this one is a bit better
<http://wiki.list.org/DOC/4.45 The admin web interface is not saving my changes and may or may not ask me to re-enter my password -- what is wrong?>
We need a way to generate short URLs for this wiki. The old Confluence tiny URLs work through a remapping process, but we don't yet have a way to generate new ones. It's on my list ...
Hi Mark,
Well, I thought the requests had disappeared but I was wrong. I'm not sure why they seemed to be gone other than operator error. In any case I searched through the logs and found nothing except this:
192.168.0.102 - - [02/Feb/2015:15:51:30 -0500] "POST /mailman/admindb/mailman HTTP/1.1" 302 222 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0"
Which is perfectly normal. I guess I need to turn on some kind of debug to see what this thing is doing. Thanks.
On 02/04/2015 05:25 AM, Dennis Putnam wrote:
Well, I thought the requests had disappeared but I was wrong. I'm not sure why they seemed to be gone other than operator error. In any case I searched through the logs and found nothing except this:
192.168.0.102 - - [02/Feb/2015:15:51:30 -0500] "POST /mailman/admindb/mailman HTTP/1.1" 302 222 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0"
Which is perfectly normal. I guess I need to turn on some kind of debug to see what this thing is doing. Thanks.
When you go to the admindb page for the list, look at the exact URL of the page in the address bar. Then depending on what you actually do, i.e. accept/reject/discard message(s) from the summary page or go to a detail link and accept/reject/discard message(s) from there, look at the exact URL of any other pages in the address bar and also look at the source of all the pages you visit for the URLs in action= elements in form tags and the URLs in links you visit.
Do all these have the exact same host name (relative actions/links are the same host as that of the URL of the page and are OK) and scheme? You are looking for anything different, i.e. a different host or scheme (http vs. https).
One common way this occurs is the form action on an https page is an http url which gets redirected by the web server to https. The redirect loses the POST data. This is covered in the FAQ at <http://wiki.list.org/x/4030602> but you may have missed it.
If you need more than that, you'll have to add debug logging to Mailman/Cgi/admindb.py such as
after
def main(): global ssort <- you may not have this line # Figure out which list is being requested parts = Utils.GetPathPieces()
add
for p in parts:
syslog('debug', 'Part from Utils.GetPathPieces(): %s', p)and after
# Make sure the user is authorized to see this page.
cgidata = cgi.FieldStorage(keep_blank_values=1)add
for k, v in cgidata.items():
syslog('debug', 'cgidata: %s: %s', k, v)This will write entries to a 'debug' log in Mailman's logs/ directory (or /var/log/mailman/debug in RHEL/CentOS) and you can then see if the script is actually getting the things it should be getting.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2/5/2015 12:40 AM, Mark Sapiro wrote:
On 02/04/2015 05:25 AM, Dennis Putnam wrote:
Well, I thought the requests had disappeared but I was wrong. I'm not sure why they seemed to be gone other than operator error. In any case I searched through the logs and found nothing except this:
192.168.0.102 - - [02/Feb/2015:15:51:30 -0500] "POST /mailman/admindb/mailman HTTP/1.1" 302 222 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0"
Which is perfectly normal. I guess I need to turn on some kind of debug to see what this thing is doing. Thanks.
When you go to the admindb page for the list, look at the exact URL of the page in the address bar. Then depending on what you actually do, i.e. accept/reject/discard message(s) from the summary page or go to a detail link and accept/reject/discard message(s) from there, look at the exact URL of any other pages in the address bar and also look at the source of all the pages you visit for the URLs in action= elements in form tags and the URLs in links you visit.
Do all these have the exact same host name (relative actions/links are the same host as that of the URL of the page and are OK) and scheme? You are looking for anything different, i.e. a different host or scheme (http vs. https).
One common way this occurs is the form action on an https page is an http url which gets redirected by the web server to https. The redirect loses the POST data. This is covered in the FAQ at <http://wiki.list.org/x/4030602> but you may have missed it.
If you need more than that, you'll have to add debug logging to Mailman/Cgi/admindb.py such as
after
def main(): global ssort <- you may not have this line # Figure out which list is being requested parts = Utils.GetPathPieces()
add
for p in parts: syslog('debug', 'Part from Utils.GetPathPieces(): %s', p)and after
# Make sure the user is authorized to see this page. cgidata = cgi.FieldStorage(keep_blank_values=1)add
for k, v in cgidata.items(): syslog('debug', 'cgidata: %s: %s', k, v)This will write entries to a 'debug' log in Mailman's logs/ directory (or /var/log/mailman/debug in RHEL/CentOS) and you can then see if the script is actually getting the things it should be getting.
Hi Mark,
They all look consistent to me.
https://server/mailman/admindb/...
I will try your debug sometime this weekend. Thanks.
participants (2)
-
Dennis Putnam -
Mark Sapiro