Forum OpenACS Q&A: users having trouble registering

Request notifications

Collapse
Posted by Janine Ohmer on
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.

Collapse
Posted by Michael A. Cleverly on
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.
Collapse
Posted by Tom Jackson on

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.

Collapse
Posted by Michael A. Cleverly on
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.

Collapse
Posted by Benjamin Bytheway on
I worked with Michael to find/fix this problem, and IIRC the problem affected both IE 5.5 and 6.0.
Collapse
Posted by C. R. Oldham on

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.

Collapse
Posted by MaineBob OConnor on

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

Collapse
Posted by Janine Ohmer on
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?

Collapse
Posted by MaineBob OConnor on
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

Collapse
Posted by Janine Ohmer on
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.

Collapse
Posted by David Kuczek on
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

Collapse
Posted by Michael A. Cleverly on
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.

Collapse
Posted by David Kuczek on
Michael,

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

Thanks

Collapse
Posted by Roberto Mello on
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.
Collapse
Posted by Andrew Piskorski on
See also some additional info in this newer May 2003 thread.
Collapse
16: Form data lost on IE/SSL (response to 1)
Posted by Jose Mendez on
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.