Forum OpenACS Development: Cookies and Port numbers with Mozilla and OpenACS

A co-worker pointed out to me that different Mozilla versions seems to have been swinging back and forth on whether the port number should be included in cookies or not. Bugzilla bug 142803 discusses this, and also references an older bug 99311 entered by Hrvoje Niksic back in 2001 when he was working at aD.

This same issue has definitely been discussed here before, in Sept. 2002 and Feb. 2003 (And here are some other threads that might also be relevent threads, from: April, May, and June 2002.)

The Bugzilla entries say that the relevent RFCs (2109 and 2965) specify that "cookie domain" defaults to the request-host, and that request-host does not include the port. However, that bugzilla bug report does not seem to say anything at all about what Mozilla's behavior is or should be when the cookie domain is not allowed to default, but is explicitly given by the server setting the cookie.

I did not really read the RFCs, however, am I correct in assuming that the above means we can get whatever behavior we want if the OpenACS code always specifies the cookie domain?

In OpenACS 4.6.2, ad_set_cookie and ad_set_signed_cookie do include a -domain option, but none of the other code in OpenACS (basically just stuff in acs-tcl/tcl/security-procs.tcl) every seems to specify -domain at all.

So... several general questions:

  1. Do the Mozilla people currently (finally?) have it right? Are they leaving anything out, or should anyone here contact them further?

  2. What exactly is the current status of cookie handling in OpenACS? Under what scenarios of current or possible Mozilla behavior will current OpenACS work correctly with sites using port numbers in the URL? What about in combination with SSL? What can or should be changed to make OpenACS work with different (all?) scenarios? (And what about IE?)
We've run into an IE cookie problem a number of times in the last year or so.

The problem comes about when you have two openacs instances running on the same time domain, with one at a different host.  For example: domain.com and host.domain.com.  If you login to domain.com first and then try to login to host.domain.com you won't be able to.

When you go to host.domain.com, IE will look at its cookies and see one for domain.com and hand it to host.  host.domain.com will look at the session_id and decide that it's an invalid session (since its a domain.com session) and send you to a login page.  After logging in, host.domain.com will try to set the ad_session_id cookie.  IE gets the cookie,  looks at the domain.com ad_session_id cookie and decides that host. doesn't have the right to change it, so it ignores the cookie.  Then host.domain.com asks for the updated cookie (redirecting after login) and IE passes it the wrong cookie again, putting the user in a loop.

The way we have overcome this on our sites is to prepend name of the host to the cookie the host.domain.com box serves up.  That way, the two servers don't set cookies with the same name.

My recommendation would be to have a kernel parameter that would allow admins to define arbitrary text that would be prepended to the cookie name (ie. host_ad_session_id).