We've also seen the same thing (with ACS 4.2)... very sporadic and extremely hard to duplicate. Question: do you have reports of this happening with anyone not using Internet Explorer? My suspicion is that it's related to the IE problem discussed in this thread.

Tom,

We run ACS 4.2 on our public site (deseretbook.com), and use OpenACS for our Intranet (let's call it intranet.deseretbook.com), which is not accessible to the public.

Some versions of IE--I forget which exactly, though I think it was 5.5, will send back cookies for the wrong host.

For example, if an employee logged into the public website initially the ad_session_id cookie (and the various others) would get set for DeseretBook.com.  Then when they went to log into the internal Intranet site IE 5.5 would send that cookie.

OpenACS would attempt to validate the ad_session_id token. Naturally this validation would fail since each site uses totally different sec_security_tokens, so OpenACS issues a new ad_session_id cookie for intranet.deseretbook.com.  However, IE would refuse to set the cookie because it already had one(!) and the two hosts didn't match (intranet.deseretbook.com != deseretbook.com).

Inspite of nominally having Netscape as the "official" internal web browser, far too many people still used IE.  We ended up modifying the ad_get_cookie and ad_set_cookie procs on the OpenACS side to pre-pend a unique identifier to the cookie name(s) being get/set.

I think this is by design. Otherwise you couldn't run servers on non-standard ports and have a login on the http side be recognized by the https side.

There is some discussion about this in Bugzilla for Mozilla--I started to report the opposite behavior as a bug in Mozilla (the cookie spec says the port number should be left off when comparing hosts).

See the Bugzilla page for bug #142803

It looks like they might be leaning toward leaving the existing behavior in--that concerns me because it means that users of Mozilla trying to login to OpenACS sites that run on nonstandard ports and restrict login to SSL will not be able to login. They will reach the SSL page and login, but the cookie will be set for the SSL side. Returning to the non-SSL side will cause them to not be logged in anymore.

I've asked the client to start asking the folks who report this what browser they are using;  I'll come back to this thread with a summary when I get some data from him.

Has anyone done any Googling to verify that this is a problem for folks running Apache/IIS/iPlanet/whatever sites, and not just us?

One problem we've run into is that the browsers have internal limits on how large a form can be.  nybooks has very long articles, and there are some which can only be edited with Netscape because it handles longer forms than IE does.  There are some which cannot be edited via the web at all unless they are broken up into smaller chunks.  This problem is somewhat insidious in that the browser will just truncate the form, and if you don't get any errors from missing variables then you'll happily go on, not realizing that the user's text has been chopped off at the knees.

If there are variables in the form after the long chunk of data we get the "problem with your input" message.  That may be why you see this on forum posts, if you have very long-winded users.  It would almost have to be a copy-n-paste situation, though;  I think the limit is something like 32K, and it's not likely that someone's going to type in that much data in a forum posting.

Since the bboard will make a mess of backslashes, rather than post the (short) bit of code inline, I've uploaded it to file storage.

It's an -init.tcl so it gets sourced after all the -procs.tcl have been at startup. It refines ad_get_cookie and ad_set_cookie to prepend the value of [ns_info hostname] to the name of the cookie.

Michael, I think this is something you should submit as a patch in the SDM, as it seems it could be integrated into the 4.6 release, and is important enough.

We recently implemented SSL  on our server and we are experiencing the same problem with Internet Explorer.
Everytime a forms is sent over SSL, ad_page_contract compains that the form elements were not sent.

We have done some testing and this problems appears to only affect IE as we have not been able to replicate it in Mozilla, Firebird, or Opera.  Another thing is that it does not happen when we use the standard HTTP.

We have added code to rp_handler to try and identify what is happening and the one thing that we see is that whenever this happens, the request arrives to the server with no form data.  It's like the browser never sent the form or as if it got lost  somewhere along the way.

We've tried setting the KeepAliveTimeout to zero on the configuration file but it didn't make a difference. I'm also not sure that it has anything to do with any redirecting problems as I don't see any messages in the log reporting a redirect by rp_filter prior to the messages by rp_handler.

Any ideas? Thanks.