I've been working on LoginManager plugins this week, and I thought things were going very well. They are not going quite as well as I thought. I need to authenticate people using kerberos. Right now my plan is to just see if kinit fails using expect and maybe write python-kerberos bindings later. As a result, authenticating people is quite expensive, or at least it will be once it works :) But it's not our kerberos setup, so we need to protect the passwords or we'll get in trouble. So we need to initially authorize the person over a secure connection and then give them a cookie to authenticate them later over insecure connections. The BasicCookieLogin plugin just stores the password in the cookie, which is not good for us, so I wrote a RandomCookieLogin which puts a random number in the cookie and changes it every time they reauthenticate (load a page). It's not perfect security, but it's better than nothing. It all seems to work fine on my local machine, but then I realized that I'm going to need to be doing a move between port 80 and 81 with the cookies, which might complicate things. So I started testing cookies when I changed Zope's port, and it wasn't good. Shouldn't cookies work on all ports of the same machine? That was my understanding from skimming the RFC (why are those things so long?!) But they do not. If I authenticate while Zope is on port 80, restart Zope on port 81, the cookie is not reused. Of course it's conceivable that restarting the server killed the cookies (they don't work when I restart it on 80). If someone will just say "It's ok, Andrew, cookies will still work on the real setup; we've moved them from 80 to 81 and back all the time" I would be very happy. Is this something people have dealt with successfully? On a related note, I have experienced other forms of weirdness using cookies in Zope. I put "raise 'CookieError'" into _cookie_list in HTTPResponse.py to see when it was getting called. The traceback generated has a line something like this: File "lib/python/ZPublisher/HTTPResponse.py", line 213, in __str__ headersl=headersl+self._cookie_list() which seems just fine, as that is the way it gets called. But that text is on line 723. Line 213 has absolutely nothing to do with cookies. This certainly seems like more a Python bug than a Zope bug, but it's confusing (may not even be a bug, though I have trouble seeing how this would not be one). Also... (sorry!) if I try to add a domain field to a cookie, netscape does not take the cookie (I have warn before accepting cookies, so I can tell what's going on). Lynx seems to take it, but I'm not too worried about supporting thte lynx market. The header information that Zope's generating seems to be well-formed, but Netscape won't make the cookie. Has anyone used the domain field on cookies successfully? Andrew