Repair a problem with cookie paths reported by Tokio when HTTPRunner is used

but a reverse proxy maps our wsgiref server into an upstream server's web
space.

Here's the basic problem: the Set-Cookie header we return has a Path attribute
which must match subsequent request uri's in order for the client to send the
cookie data back to us later in a Cookie header of that subsequent request.
The problem though is that we cannot guarantee that we know how our wsgi
server is mapped into the upstream proxy.  It's probably '/mailman/' for
backward compatibility, but there's no way for us to tell, because there's
nothing specifically included in the request that tells us what the originally
requested uri is.

If we get the cookie path wrong, the effect is to require a login every time
an admin page is hit, because the client will not see a matching path prefix
and will not send us the cookie data.

We solve this (albeit, by hack) by looking at the HTTP_REFERER environment
variable we see.  This will point to the admin login page on which the admin
password was entered.  We'll pick this uri apart to attempt to find the prefix
at which our wsgi server was mapped.  If we find this, we'll use it to craft
an appropriate cookie path.  Hopefully.  If that cgi environment variable is
not available, we just return the path as we've seen it.

This approach allows for accessing the admin pages either through a reverse
proxy or directly, with no additional configuration necessary.  In fact, both
access mechanisms can work at the same time; try hitting these two uri's with
different browsers:

    http://example.com/mailman/admin/mylist@example.com/general
    http://example.com:2580/admin/mylist@example.com/general

The first will hit our reverse proxy, and the second will hit our wsgi server
directly.  The responses will included two different cookie paths, but both
will work!  This is an important principle to uphold, especially for debugging
purposes.  Note that I could have added a configuration variable to handle the
cookie path remapping, but then we'd have to support either the reverse proxy
or the wsgi server, but not (easily) both.  Plus, it's another configuration
variable.  Yuck.

Note that Apache 2.2 has something called the ProxyPassReverseCookiePath
directive, which should probably be used if available.  It's not in Apache
2.0, which is probably the most prevalent server in use with Mailman right
now, so we can't count on it.  Plus, if ProxyPassReverseCookiePath is
available, our algorithm should still work.

What about other proxy servers?  Dunno.  We'll have to wait for feedback from
users.

This change also fixes a buglet with MTA/Postfix.py when
POSTFIX_STYLE_VIRTUAL_DOMAINS is used.  You can end up trying to call
_update_maps() before data/aliases exist.  This just defers that call until
it's guaranteed both the transport and the alias files have been created.

Also, finish converting SecurityManager.py to use the configuration object
(and the Defaults module where appropriate) instead of mm_cfg.py.

0 files changed, 0 insertions, 0 deletions