Amending list web_page_url attribute on Python2.1a3
I'm using MM 2.1a3 off sourceforge to redevelop my mailman-htdig integration patches; I'm work with the mailman-2.1a3.tgz download not from CVS.
With MM 2.0.X amending a list's web_page_url attribute could be done directly at the bottom of the General admin page.
With MM 2.1a3 the field at the bottom of the General admin page is now the host_name attribute.
MM 2.1a3 admin page lets me change the host to for the list but I cannot see any way on the list admin pages to change the addressing scheme for the list, e.g from http to https.
Have I missed something or am I reduce to using $prefix/bin/withlist?
"RB" == Richard Barrett <R.Barrett@ftel.co.uk> writes:
RB> MM 2.1a3 admin page lets me change the host to for the list
RB> but I cannot see any way on the list admin pages to change the
RB> addressing scheme for the list, e.g from http to https.
RB> Have I missed something or am I reduce to using
RB> $prefix/bin/withlist?
Yes, because too many list admins f*cked up their lists by typing an incorrect or unreachable url prefix there.
The best way to solve this globally is to set mm_cfg.DEFAULT_URL_PATTERN and mm_cfg.DEFAULT_URL_HOST to whatever you want (e.g. http -> https). All newly created lists after this change will simply inherit these new values.
To fix existing lists, use withlist and fix_url.py (this latter is in cvs; I'm not sure if it made it to alpha3).
% bin/withlist -r fix_url -l mylist
-Barry
At 23:32 06/12/2001 -0500, Barry A. Warsaw wrote:
"RB" == Richard Barrett <R.Barrett@ftel.co.uk> writes:
RB> MM 2.1a3 admin page lets me change the host to for the list RB> but I cannot see any way on the list admin pages to change the RB> addressing scheme for the list, e.g from http to https. RB> Have I missed something or am I reduce to using RB> $prefix/bin/withlist?
Yes, because too many list admins f*cked up their lists by typing an incorrect or unreachable url prefix there.
The best way to solve this globally is to set mm_cfg.DEFAULT_URL_PATTERN and mm_cfg.DEFAULT_URL_HOST to whatever you want (e.g. http -> https). All newly created lists after this change will simply inherit these new values.
To fix existing lists, use withlist and fix_url.py (this latter is in cvs; I'm not sure if it made it to alpha3).
% bin/withlist -r fix_url -l mylist
-Barry
While I understand why you've gone this route, I think it is the wrong approach.
Say a user wants to protect Web UI access to some sensitive lists and only make them available via HTTPS with client side certificates, while other of the site's lists are available via HTTP. Setting this up now becomes a real pain in Mailman. I'd have to temporarily change mm_cfg so that fix_url will pick up the desired addressing scheme from DEFAULT_URL, pray no other admin creates a new list while this change is in place or we'll be recursing to fix their newly created problem, run withlist and then hastily revert mm_cfg. Alternatively I can run withlist raw (without hacking mm_cfg) to change the list's web_page_url, which is even more error prone. Yes, I know that isolating the sensitive lists so that the server will only serve them through port 443 is also a pain but that's an Apache config issue not a Mailman problem.
I say it would be better to offer a selection of addressing schemes (probably only http and https) for a list using a SELECT/OPTION tags at the end in the General Options page near the host_name field. That way the code can ensure the web_page_url formed is technically valid. fix_url can still be used for recovering from major stupidity on the admin's part.
In a similar vein, the pages generated by /mailman/admin and /mailman/listinfo use relative URLs for the links to each list's admin or listinfo page. Wouldn't the full absolute URL derived from the web_page_url of each list for each list be more appropriate?
I'm willing to try and build a patch for 2.1a3 to implement these changes if you think they would be acceptable.
Richard
participants (2)
-
barry@zope.com
-
Richard Barrett