Forum OpenACS Q&A: users having trouble registering
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.
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.
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.
- ...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.
Has anyone done any Googling to verify that this is a problem for folks running Apache/IIS/iPlanet/whatever sites, and not just us?
- 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.
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.
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...
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.
does your hack also work for 3.2.5 or would I have to change things?
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.