Closed Bug 30953 Opened 20 years ago Closed 20 years ago
Unable to Login
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; N; Linux 2.2.13-7mdk i586; en-US) Mozilla/m13 BuildID: 2000022916 I am unable to Login to our Administation side of our product with Mozilla. I have set up a test site for you above. User Name: ADMIN Password <BLANK> It works with Netscape & IE. I am a bit mistified by this one, since the user side of the product works fine with mozilla. http://westfork.rightnowtech.com/cgi-bin/nealr All of the parameters to the app are located in the <FORM> section of the page. I have debugged the application on my side and found that the form <input> tags are not recieved properly. M-13 exhibited the same result. Reproducible: Always Steps to Reproduce: 1. Goto http://westfork.rightnowtech.com/cgi-bin/nealr 2. Enter ADMIN & <blank> and hit Login button. Actual Results: Unable to Login! Expected Results: Shown an administative page. Login with Netscape to see it. See description.
This is a browser bug, not a doc bug. Reassigning to rods (I guess it's a form thing).
Assignee: rudman → rods
Component: User → Form Submission
Product: Documentation → Browser
Version: unspecified → other
eric, this may be a sumbit issue
Assignee: rods → pollmann
Your CGI is failing because it depends on the order of the varables in the post data. The order they actually appear in the document is: _22, _23, _129 We post them in this order: _129, _22, _23 -------- POST DATA -------- POST /cgi-bin/nealr/administration HTTP/1.0 Host: westfork.rightnowtech.com User-Agent: Mozilla/5.0 (X11; N; Linux 2.2.12-20 i686; en-US; m14) Accept: */* Accept-Language: en Referer: http:///westfork.rightnowtech.com/cgi-bin/nealr/login cookie: USER_ID=126.96.36.199-3902392960.29329365; VER=3.51; PersonalLogin=name%3Aadmin%20key%3A%20remember%3Aundefined Content-type: application/x-www-form-urlencoded Content-Length: 20 _129=&_22=admin&_23= -------- POST DATA -------- I reordered them and manually posted, things worked fine. We sometimes have to reorder the variables because the document came in from the server in two packets, and the second one caused the frames (widgets) for the inputs in the first packet to be recreated and thus added to the end, after the later ones. This is not part of the HTML or HTTP spec, but it should be fixed anyway. This is already reported as bug 18728, so I'm marking it a duplicate. If you would like to fix your site in the short run, you'll have to replace the logic that assumes that the variable/value pairs are coming in the same order that they appear in the document. Thanks! *** This bug has been marked as a duplicate of 18728 ***
Status: NEW → RESOLVED
Closed: 20 years ago
OS: Linux → All
Hardware: PC → All
Resolution: --- → DUPLICATE
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.