Mailman 3 July 2000 - Mailman-Developers

Re: [Mailman-Developers] cookies
by Hrvoje Niksic 20 Jul '00

20 Jul '00

bwarsaw(a)beopen.com (Barry A. Warsaw) writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > Hrvoje> What version of Mailman is that? > > Current CVS snapshot. Oh, I see. Is there maybe a patch that fixes the "Error decoding ..." problem for us who run the released beta?

2 1

Re: [Mailman-Developers] cookies
by Hrvoje Niksic 20 Jul '00

20 Jul '00

bwarsaw(a)beopen.com (Barry A. Warsaw) writes: > def hexlify(s): > acc = [] > - def munge(byte, acc=acc, a=ord('a'), z=ord('0')): > - if byte > 9: acc.append(byte+a-10) > - else: acc.append(byte+z) > + def munge(byte, append=acc.append, a=ord('a'), z=ord('0')): > + if byte > 9: append(byte+a-10) > + else: append(byte+z) ... What version of Mailman is that? I'm using 2.0beta4 and can't find anything resembling hexlify in the sources. I ask because I do see "Error decoding authorization cookie" messages and would like to fix them.

2 1

Re: [Mailman-Developers] cookies
by Harald Meland 20 Jul '00

20 Jul '00

[Ricardo Kustner] > Hi, > > On Tue, May 09, 2000 at 09:12:49PM +0200, Harald Meland wrote: > > > > Please write a patch which puts the string "Cookie could not be set" on the > > > > web page so that I can see that pressing submit will not work :-) > > > i think thats a good point... it would safe some user questions if > > > MM tells exactly why the authorisation failed. > > While I agree that such a warning would be nice, I don't think it's > > possible to do such things with cookies. > it's possible to set a test cookie to see if cookies are > enabled... Ahh, I didn't even think of using multiple cookies :) If I understand you correctly, you're proposing something like this: Whenever Mailman is about to write a login page (i.e. the user is not already authenticated), it first issues a Set-Cookie: Mailman_cookie_test="This cookie is only used to test whether your browser will be able to authenticate with Mailman"; Version=1 HTTP header (If other Mailman cookies set attributes like Path or Domain, the test cookie should mirror these to make the test reflect real usage). Next, once the user has pressed the "Let me in..." button, Mailman checks whether the Cookie has been sent back. If it hasn't, authentication fails (as the user won't be able to make any changes anyway), and Mailman instructs the user to enable Cookies in her browser before retrying login. If the test Cookie is present, Mailman should issue a Set-Cookie: Mailman_cookie_test="clickety click"; Max-Age=0; Version=1 HTTP header (to delete the test cookie, so that the test cookie isn't later confused with test cookies for login attempts at other lists). Finally, Mailman proceeds with password authentication as usual, possibly resulting in an authentication cookie. Hmmmm... I guess the test cookie should contain info on what list it is for, as well. Have I understood you correctly? Does anyone think that implementing this (apart from my misunderstandings, of course :) would be a bad thing? And, while we're talking about cookies: Does anyone know whether switching from the cookie attribute "Expires" (which was part of the original Netscape cookie proposal) to the RFC2109 cookie attribute "Max-Age" is likely to cause any problems? I've had a look at Cookie.py, and the value part of the Expires attribute isn't enclosed in double quotes (in accordance with the original Netscape cookie proposal), which I believe might confuse Mailman in some situations where the browser sends back more than one cookie. Of course, if there are any (major) browsers in use out there that doesn't understand Max-Age, it would be a bad idea to change Mailman. -- Harald

5 5

Cookie odditity - possible bug in 2.0b4?
by Nigel Metheringham 20 Jul '00

20 Jul '00

I just went to deal with the held messages for one of my lists. As usual I was asked for the appropriate password, and then offered a cookie (I have netscape set so I have to accept/deny them). This cookie looked rather short compared to the normal ones, but I accepted anyhow. Then when I approved the held message I was again asked for authentication, and this time given a cookie of normal length. Is mailman generating corrupt cookies under some circumstances. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

1 0

exit 11 Seg fault problem: not mailman
by Chuq Von Rospach 19 Jul '00

19 Jul '00

I've pretty much concluded this error I'm seeing isn't mailman. Right now, it looks instead to be PHP, which, I now realize is still at 4.0, not the patch, and therefore prone to this. It showed up when I upgraded to mailman because I also added a php-based tool at the same time, and it's tweaking PHP in some way. mutter. sorry for the false alarm... -- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com) And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"

2 1

Cookie problems
by Dan Mick 19 Jul '00

19 Jul '00

So, as I noted on mailman-users, I've been spending some time examining the cookie stuff. I found two things that raised my hackles a bit: 1) MakeCookie (in SecurityManager.py) is careful to keep track of "expires" as an int (converting the 'issued' time to int before adding ADMIN_COOKIE_LIFE), but "issued" remains a float. Floats for hard comparisons always make my hackles rise. 2) MakeCookie sets c[key]['expires'] to mm_cfg.ADMIN_COOKIE_LIFE, not to 'expires', which is calculated above; that means the cookie object doesn't have the 'issued' time added into its 'expires' field. Given that MakeCookie is apparently the source of the HTTP output, this seems wrong too.. seems like the Expires time is always going to be just the lifetime, not the actual expiry date. Am I misreading something?

2 1

"error decoding authorization cookie"
by Chuq Von Rospach 19 Jul '00

19 Jul '00

I started seeing this tonight. Here's what I was doing... I was working on multiple lists at once -- I'd brought up a first window and signed in to edit a list "../mailman/admin/ahl/...". I then brought up a second window to check some configuration options "../mailman/admin/test/...". That second window kept getting the cookie failures and having me log in again. I closed the second window, went back to the first, and it's fine. So one version of this failure is if you're trying to do two things at once, because the authorization setup can't handle it. Is this something others who's seen this were trying to do, maybe had another admin window open without realizing it? chuq -- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com) And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"

2 1

Re: [Mailman-Developers] Bug Found in Mailman
by Harald Meland 19 Jul '00

19 Jul '00

[Ricardo Kustner] > On Wed, Jun 07, 2000 at 04:21:06PM +0200, Andrea Paparelli wrote: > > Bug in Mailman version 1.1 > > File "/home/staff/mailman/Mailman/SecurityManager.py", line 117, in > > CheckCookie > > if cookiedata[keylen+1] <> '"' and cookiedata[-1] <> '"': > > IndexError: string index out of range > > I stumbled on this a few times too... but it is very hard to reproduce... > what I think went wrong in my situation most of those times is that somehow > the cookie got mixed up with a different cookie which was set by a different > program at the exact same server as mailman... > anybody had simular experiences? I haven't seen this happen with my users, but as the offending piece of code indeed is a hack that won't work reliably if the browser sends multiple cookies, I think this should be addressed somehow. The real problem, I think, is that there's confusion on the subject of cookie content syntax. The original Netscape proposal uses this (not very well-defined, IMO) cookie content syntax: : NAME=VALUE : This string is a sequence of characters excluding semi-colon, : comma and white space. If there is a need to place such data in : the name or value, some encoding method such as URL style %XX : encoding is recommended, though no encoding is defined or : required. A quick example: [ Server -> Client ] Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT [ Client -> Server ] Cookie: CUSTOMER=WILE_E_COYOTE Note that there are no quotes around the cookie value. RFC 2109, however, has a more well-defined, but ever so slightly different content syntax: : 4.1 Syntax: General : : The two state management headers, Set-Cookie and Cookie, have common : syntactic properties involving attribute-value pairs. The following : grammar uses the notation, and tokens DIGIT (decimal digits) and : token (informally, a sequence of non-special, non-white space : characters) from the HTTP/1.1 specification [RFC 2068] to describe : their syntax. : : av-pairs = av-pair *(";" av-pair) : av-pair = attr ["=" value] ; optional value : attr = token : value = word : word = token | quoted-string Note that the cookies value can be a quoted-string. The example from the Netscape spec could look like this using the RFC syntax: [ Server -> Client ] Set-Cookie: CUSTOMER="WILE_E_COYOTE"; Version="1"; Path="/"; Max-Age="3600" [ Client -> Server ] Cookie: $Version="1"; CUSTOMER="WILE_E_COYOTE"; $Path="/" (Some time back) I looked over misc/Cookie.py trying to find some way to make it cope reliably with both kinds of cookies, but wasn't really able to discover what's wrong with _CookiePattern :( I suspect that using "Max-Age" attributes on Mailman cookies instead of the current (non-RFC) "Expires" attribute *might* help, but I really don't have any idea whether such a change will stop Mailman from working with certain browsers. -- Harald

2 1

Membership management chunking requires two authentications..
by Ted Cabeen 19 Jul '00

19 Jul '00

Mailman: 1.1 Python: 1.5.2 OS: Solaris 5.7 I don't know if this has been fixed in the CVS version, but I thought I'd submit it anyways. There seems to be a small authentication bug with the chunking in the membership management page. The page will load up correctly the first time it is accessed with the first chunk size shown. However, when you request a different chunk, it requires a reauthentication and then gives the chunk=0 page instead of the requested chunk. If you then click on the alternate chunk it loads fine. However, the additional click and authentication is annoying. -- Ted Cabeen http://www.pobox.com/~secabeen secabeen(a)pobox.com Check Website or finger for PGP Public Key secabeen(a)midway.uchicago.edu "I have taken all knowledge to be my province." -F. Bacon cococabeen(a)aol.com "Human kind cannot bear very much reality."-T.S.Eliot 73126.626(a)compuserve.com

3 4

HyperArch
by Cristian Prevedello 19 Jul '00

19 Jul '00

i'm writing a program to approve requests from command line. I don't know mailman internals, so i just went throught the source looking how ListAdmin do the Accept/Reject/... I'm doing it fine, but i've a problem. When i do a Post, i got the following error from a background process(i think): (Cmd) Traceback (innermost last): File "/var/lib/mailman/Mailman/Archiver/Archiver.py", line 242, in ArchiveMail h.close() File "/usr/lib/mailman/Mailman/Archiver/HyperArch.py", line 907, in close self.update_dirty_archives()# Update all changed archives File "/usr/lib/mailman/Mailman/Archiver/HyperArch.py", line 870, in update_dirty_archives self.update_archive(i) File "/usr/lib/mailman/Mailman/Archiver/pipermail.py", line 322, in update_archive article=self.database.getArticle(self.archive, msgid) File "/var/lib/mailman/Mailman/Archiver/HyperDatabase.py", line 276, in getArticle article = self.__cache[msgid] = pickle.loads(buf) ImportError: No module named HyperArch i'm using Mailman version 1.1. Any idea? -- Cristian Prevedello, System Administrator, Linuxcare Italia spa +39.049.804.3.411 tel, +39.049.803.6.484 fax plasma(a)linuxcare.it, http://www.linuxcare.com/ Linuxcare. Support for the revolution.

2 1