[Mailman-Users] mailman (+vexim +exim) -- web interface uses absolute urls... to elsewhere

[will trillich]

my original missive should've been more thorough. i can see that now. :)

On 5/9/06, Richard Barrett <r.barrett at openinfo.co.uk> wrote:
> On 9 May 2006, at 04:16, will trillich wrote:
> > On 5/8/06, Patrick Bogen <pdbogen at gmail.com> wrote:
> >> Check your setting in DEFAULT_URL_PATTERN. See FAQ 4.29:
> >>
> >> http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.029.htp
> >
> > thanks for the pointer. turns out, ours is set exactly right. it's
> > perfectly fine.

according to http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.029.htp
we can plop 'https://%s/mailman' into DEFAULT_URL_PATTERN and it'll
determine where the links go when creating those cursed (and
unnecessarily) absolute urls.

but it's still not cooperating. it's IGNORING that variable. during
execution, that variable is parsed, because if we take out the "%s" it
dies a painful python death. but so long as it has "%s" then the rest
of the string does not matter, and we get redirected to our
alternative virtual site no matter what.

> > since DEFAULT_URL_HOST didn't appear to be used in the final analysis,
> > we tried DEFAULT_URL instead (with the short-circuit approach, it
> > would override). alas, no luck.

DEFAULT_URL_HOST is definitely NOT what determines the links we're
having trouble with.


> If you want https for everything then follow the link from:
>
> http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.029.htp

apache is serving up secure https just fine. we've got that part covered.

okay, just to be sure that DEFAULT_URL_PATTERN is referenced
SOMEWHERE, we changed it to 'bad-url-pattern' and sure enough, it
bombs out with a serious python error (no %s in the string for the
argument passed to the '%' operator).

so we changed it to 'where%s the beef?' and then everything worked
just fine. all links STILL pointed to the other (wrong) virtual site,
without secure https. plus, forms are also sent in the clear, to the
wrong site. NO absolute links should be working at all in that case,
right? IF the variable were being used, that is. it's clearly NOT
being used in generating these links.

i'm very new to python (coupla hours, now) -- so following library and
module calls is quite alien to me. any chance i could munge the
href-generator algorithm to generate relative links? absolute links
are handy when taking cross-site jumps into account as a possibility
-- but with cookies and authentication that would be counter
productive anyway. links should look like

  ../../other/path

NOT

  http://proper.server.name/on/a/good/day/other/path

at the very least, if we're going to insist on an absolute website for
the html doc, it should be placed in the <base> tag, and then all the
other links should STILL be relative.


> If you diligently follow _all_ the instructions in the FAQ entries,
> including the comments regarding virtual hosts, the VIRTUAL_HOSTS
> Python dictionary, restarting mailmanctl and  judicious use of

is it simple to dump the virtual_hosts dictionary? maybe there's
something in there that we don't want. better, would be to massage the
href-generator routine.

> fix_url for existing lists you will get a consistent set of
> appropriate URLs produced on the MM web GUI. You also need to read
> the bin/newlist usage to understand the way that you can assign new
> lists to web and email hosts when creating them which again links to
> the understanding and setup of VIRTUAL_HOSTS Python dictionary in
> mm_cfg.py. Also, if you find yourself fooling with the list's
> host_name attribute through the admin GUI "Host name this list
> prefers for email" option then it is probably time to stop and review
> you mm_cfg entries etc.

don't mean to sound too grumpy, but i think i've been pretty diligent.
and we don't have any existing lists yet, as we're still trying to get
this bad boy to straighten up and fly right.

if we can have DEFAULT_URL_PATTERN set to "?x:%s:z!" and the site
still works, then there's something very very wrong under the hood.
(could be MY hood, sure, but the point stands. :)

your talking from the perspective that it's working sanely. my debian
setup is currently not aligned with your paradigm, but i'd love it if
it were. :)

--
will trillich
"Their is five errers in this sentance."