[Mailman-Developers] Amending list web_page_url attribute on Python2.1a3

[Richard Barrett]

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