Forum OpenACS Q&A: users having trouble registering

Posted by Janine Ohmer on 09/09/02 10:15 PM

One of our sites, based on ACS Classic 4.2, gets several user
complaints per week from people who filled out the form at
/register/user-new, then got a "problem with your input" complaint
after hitting the Register button. Basically, all the data they
entered has disappeared on the way to user-new-2.

I've had it happen to me too, but it's very sporadic and I've never
been able to figure out what's causing it. Don and I have thought it
might be a communications problem, where the form just isn't making it
from the user's browser back to the server, but it seems to be too
frequent for that.

Has anyone else seen this? Any clues as to what might be happening?
If it matters we use nsd 3.3+ad13.

2: Response to users having trouble registering (response to 1)

Posted by Michael A. Cleverly on 09/09/02 10:38 PM

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.

3: Response to users having trouble registering (response to 1)

Posted by Tom Jackson on 09/09/02 10:54 PM

I also am seeing an interesting problem with IE: I login in to for example http://example.com/, then to http://example.com:1234, somehow these two overwrite each other's cookies.

4: Response to users having trouble registering (response to 1)

Posted by Michael A. Cleverly on 09/09/02 11:05 PM

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.

5: Response to users having trouble registering (response to 1)

Posted by Benjamin Bytheway on 09/09/02 11:09 PM

I worked with Michael to find/fix this problem, and IIRC the problem affected both IE 5.5 and 6.0.

6: Response to users having trouble registering (response to 1)

Posted by C. R. Oldham on 09/09/02 11:14 PM

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.

7: Response to users having trouble registering (response to 1)

Posted by MaineBob OConnor on 09/10/02 01:34 AM

Janine:

...gets several user complaints per week from people who filled out the form at /register/user-new, then got a "problem with your input" complaint... Has anyone else seen this? Any clues as to what might be happening? If it matters we use nsd 3.3+ad13.

WE Continue with a similar problem on OpenACS 3.x and Aolserver 3.3+ad13. Occasionally with registration but more often with forum posts and other potentially long form posts.

Michael mentioned the thread in which this is discussed. Yet I have NOT found a satisfactory solution. Only a few of my Uber users have also installed Netscape / Mozilla (4x or 6x) to prevent this problem that appears to only effect users of IE 5 or 6.

I'd still like to see a satisfactory SOLUTION.

-Bob

8: Response to users having trouble registering (response to 1)

Posted by Janine Ohmer on 09/10/02 04:33 AM

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?

9: Response to users having trouble registering (response to 1)

Posted by MaineBob OConnor on 09/10/02 10:50 PM

Janine,

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

Check out this thread which has links to microsoft and a thread on another forum.

openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0003qe

-Bob

10: Response to users having trouble registering (response to 1)

Posted by Janine Ohmer on 09/11/02 05:22 PM

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.

11: Response to users having trouble registering (response to 1)

Posted by David Kuczek on 09/12/02 02:23 PM

Michael,

could you post your modified ad_get_cookie and ad_set_cookie procs?Are they a stable solution?

On IE 5.5 I just noticed the problem that whenever I log into foo.com, I am automatically logged into sub.foo.com... Additionally the procs ad_get_user_id and ad_verify_and_get_user_id return different values for user_id. One returns my user_id, while the other returns 0.

I just wanted to write a blurb for IE users stating that if they can't log in, they should kill all existing cookies. It would surely be more elegant, if they wouldn't have to bother with the cookie problem at all...

Thanks

12: Response to users having trouble registering (response to 1)

Posted by Michael A. Cleverly on 09/12/02 11:21 PM

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.

13: Response to users having trouble registering (response to 1)

Posted by David Kuczek on 09/13/02 08:38 AM

Michael,

does your hack also work for 3.2.5 or would I have to change things?

Thanks

14: Response to users having trouble registering (response to 1)

Posted by Roberto Mello on 09/13/02 04:53 PM

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.

15: Re: users having trouble registering (response to 1)

Posted by Andrew Piskorski on 05/29/03 01:37 AM

See also some additional info in this newer May 2003 thread.

16: Form data lost on IE/SSL (response to 1)

Posted by Jose Mendez on 02/20/04 10:41 PM

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.