[Mailman-Users] Cookie problems

[David Smead]

Would this have anything to do with an infinite loop on trying to view all
the member pages as admin?

I've had to enter the password after selecting the second page of members,
but then after entering the password again, I'd be able to select the
second page and get it.

Now I've given the password to another person and they get into an
infinite password loop.

I'm still running b2.

Sincerely,

David Smead
http://www.amplepower.com.
http://www.ampletech.com.

On Mon, 17 Jul 2000, Dan Mick wrote:

> First, let me make it clear that I'm just a happy Mailman user with
> some Python experience (from hacking at Mailman); don't take any
> of my comments or attitudes as "official Mailman policy" or anything.
> 
> I've seen all the complaints about admin cookies, and I've been trying
> for the last two hours to reproduce any problem (using Netscape 4.73
> on Solaris, and Mailman 2.0beta4) and I can't repro anything but the
> one problem I already knew about.
> 
> If anyone has a repro scenario, it would be interesting to hear
> about it.
> 
> Here's the one and only cookie-related hassle I know about:
> 
> Mailman wants to, by default, put everything on the web server under
> "/mailman", including the admin pages.  The default URL for admin
> pages is usually "http://host/mailman/admin/listname" (where host
> and listname are replaceable tokens).
> 
> I've experimented with making this path "/lists/", instead, by
> adding the right Alias statements to the webserver config...
> and this *sorta* works, but the problem is the admin cookies:
> they are issued based on the path configured into the list,
> by the last field on the General Options page (aka web_page_url
> in the object, seen by Python code, dumpdb, or config_list).
> 
> If the URL you first go to doesn't match the URL mentioned
> in web_page_url, you will have problems, because the new cookie
> will be made based on web_page_url, regardless of the URL
> you used to access the page. 
> 
> For instance, in my example, the webserver would serve up the
> right CGI output from "/lists/", but the cookie would have
> "/mailman/" in it, so the Mailman CGI would be convinced that
> every access was a new one...until I clicked on something
> that would generate a path with "/mailman/", and then I'd get
> a second cookie, which would remove the problem.
> 
> I never had a problem with multiple lists at the same time
> (two cookies, both named "<list>:admin", with different values,
> both stayed active as I bounced between lists and changed values
> on both.)
> 
> I never got a response of anything like the possible errors from
> admin.py:
> 
>         except Errors.MMBadPasswordError:
>             message = 'Sorry, wrong password.  Try again.'
>         except Errors.MMExpiredCookieError:
>             message = 'Your cookie has gone stale, ' \
>                       'enter password to get a new one.',
>         except Errors.MMInvalidCookieError:
>             message = 'Error decoding authorization cookie.'
>         except Errors.MMAuthenticationError:
>             message = 'Authentication error.'
> 
> I can certainly imagine that some browser/OS combinations are
> corrupting the cookie data, as it's binary and contains things like
> embedded carriage-returns; to diagnose that, I'd look carefully
> at the stored cookie value and what gets transmitted to the server
> (using a network sniffer program like Ethereal, etherfind, tcpdump,
> snoop, or whatever).  It might also be useful to add a bit of logging
> to SecurityManager.py to see what it thinks the cookie values it's
> getting are (and compare them to what the browser thought they
> were).  If someone has a persistently-reproducible problem, I'd
> be willing to work with them to insert some debug into SecurityManager.py
> privately (mail me if you fit that description).
> 
> 
> ------------------------------------------------------
> Mailman-Users maillist  -  Mailman-Users at python.org
> http://www.python.org/mailman/listinfo/mailman-users
>