Closed Bug 121355 Opened 23 years ago Closed 22 years ago

Failure to login at this site (regression, Netscape 6.2.1 works)

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 62348

People

(Reporter: andreas.premstaller, Assigned: morse)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(3 files)

Login Page, Saved
3.94 KB, text/html
Details
Transaction Log For 01/23 nightly
540 bytes, text/plain
Details
Transaction Log For 0.9.4
568 bytes, text/plain
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+)
Gecko/20020117
BuildID:    2002012008

At www.ff-online.com, you cannot see protected journal articles (the ones with
the lock in front) since login fails.

Reproducible: Always
Steps to Reproduce:
1. go to www.ff-online.com
2. click on one of the links to a protected article with a lock in front
3. a login window pops up
4. fill in the forms (I can send login information in a private mail)
5. click "login"

Actual Results:  Page sends request and comes back with the login dialog after a
while.

Expected Results:  You should be shown the article.

This works with Netscape 6.2.1 on W2K.

This is the javascript that send the 
<script language="javascript">
<!--
[...]
function login() {
  setcookie('username', self.document.login_form.username.value);
  setcookie('password', self.document.login_form.password.value);
  window.main = window.open('/php/article.phtml?issue_id=1132&rand=' +
                             Math.random(), 'main');
  window.close();
}
[...]

The cookies are set successfully (cookie manager shows the same as in Netscape
6.2.1), but something in/behind the window.open-function does not work. issue_is
indicates a unique number for the article.

Could this be the same as bug 105274 (that cannot be reproduced anymore since
the site changed)?

CC'ing Alexandru Savulov, since he wrote the following in bug 105274, comment 20:
> If it wouldn't work with 0.9.7 but work with NS6.2.1 I could
> re-milestone to 1.0, otherwise I can't do this be cause then I would
> have to explain this to the drivers why is it that important, but I
> have no arguments for that. A regression from 0.9.4 would be a 
> strong argument.
The regression occurred between milestone 0.9.5 and milestone 0.9.6. Login is
possible with release build 2001101117 (0.9.5 on Win), but not with 2001112009
(0.9.6 on Win).
Is there some archive of nightly builds available so I could isolate this a
little further?
Well, the old daily builds are thrown away. the earliest is dated  12-26-2001,
but they will also soon disappear

I will try to se who's guilty :-)

Thanks for... you know what :-)
Keywords: regression
Attached file Login Page, Saved — 
This version of the login page does not submit, instead it shows the value of
username/password and the value of document.cookie.
The funny thing is, when I come back to the login window, the username and
password are embedded in the username and password inputs, indicating that they
got to the server /somehow/.  What's up with that?  Does this work in IE?
This works with IE 5.5 and 6, as well as with Opera, and until Milestone 0.9.5
on Mozilla. 
jkeiser, I assume you got the login information from Alexandru.
the funny thing is:

if you try to login and it does not work, the login window pops up again and
here comes the clue 

- the inputs username and password are preset correctly and that is comming from
the apache-server!
So i'm sure is not the form! It has rather to do with the request that is sended
but is also not form submission since there is no submission but a combination
of   cookies and window.open(...).


From my tests, it looks like the cookie is not being sent in 0.9.7.  (This could
be because the cookies are being created just before window.open() and the
cookies are not really created yet at that point.)

Let me explain how I got that data: I wrote a little tiny server and ran it on
port 8086 of my machine.  I put the login page at http://127.0.0.1/~john/okeyto
do window.open("http://127.0.0.1:8086/php/article.phtml?issue_id=1134&rand=' +
Math.random(), 'main');

The little server just takes whatever the browser sends it and puts it to a
file.  I took those files and that is what you see there.
Assignee: alexsavulov → morse
Component: Form Submission → Cookies
QA Contact: vladimire → tever
Alex spent some hard time hitting it too, and can confirm that the URL is the
same as well as all the headers on his computer; but he was seeing the cookies
sent.  Still, this is the first lead we have.
Wonder if this could be related to bug 121397?
Maybe, but in bug 121397, comment #1 Christopher states he could log in using
0.9.6 (and not with 0.9.7 any more), while I could log in using 0.9.5, but not
with 0.9.6 anymore (all on Win). 
Can someone post exactly what cookie-manager shows for these cookies.  
Specifically, I want to see the hostname and also whether or not they are domain 
cookies (domain cookies have the label "domain" for the first field, otherwise 
the label is "host").

There was a change made regarding sending of domain cookies to hosts that are ip 
addresses, and I notice from the attachments that this is such a host.
Cookie Manager sets 3 cookies, "cookieswork" (at the very beginning), "username"
and "password". For username it says:

Site: www.ff-online.com   Cookie Name: username
Name:          username
Information:   myusername     /* did you get the login info? */
Host:          www.ff-online.com
Path:          /php/login.phtml?page=/php
Server Secure: no
Expires:       at the end of session

Site: www.ff-online.com   Cookie Name: password
Name:          password
Information:   mypassword
Host:          www.ff-online.com
Path:          /php/login.phtml?page=/php
Server Secure: no
Expires:       at the end of session

Site: www.ff-online.com   Cookie Name: cookieswork
Name:          cookieswork
Information:   12.07.2000
Host:          www.ff-online.com
Path:          /php
Server Secure: no
Expires:       at the end of session

Those cookies don't agree with Keiser posted traffic.  In his tests he was using 
a local server and the hostname was an ip address.

Can someone post traffic and cookie-list that are obtained from the same test.
The cookies *do* get set in Mozilla (they are the same as in 0.9.6), they just
weren't sent.  My theory is the cookies are not fully ready to be sent by the
time the window.open() happens (but it's just a theory).  This theory is because
JavaScript is creating the cookies just before window.open().  And it could, as
you say, be related to my sending to an IP address.  The tests may, or may not,
be invalid.

Cookies:
Name: username
Information: d
Host: 127.0.0.1
Path: /
Server Secure: no
Expires: at end of session

Name: password
Information: f
Host: 127.0.0.1
Path: /
Server Secure: no
Expires: at end of session

Alex did tests and says he *did* see cookies go across; but since this is the
first real discrepancy between 0.9.4 and 0.9.7 traffic we've found, I figured
you guys might have some better idea how to proceed than we do.

Do remember that I was submitting to a different port, which might have affected
the tests.  I am not sure how to grab the data that is going to their server.
(Those cookies were from the tests--I haven't done any 127.0.0.1 tests since
then--and they are the same as the cookies that showed up in 0.9.4.  I used
different profiles for the tests to avoid corruption.)
I don't know if this helps, but I'm going to add a comment in bug 121397 shortly
about my conversation with the help desk responsible for the site in that bug. 
I was told that Opera also has problems with the site, and it's a javascript
problem.  I'll try to dig up a little detail before I add a comment over there.
If this is somehow related to bug 121397, it isn't however an exact duplicate. 2
differences:
1. This regression occurred between 0.9.5 and 0.9.6, bug 121397 between 0.9.6
and 0.9.7
2. The page in this bug works with Opera (5.x on Win32), while the one in bug
121397 seems not to work there. 

Unfortunately, no activity on any of the bugs. Is there anything I can do to
help shed some light on this problem?
As I reported via email to the reporter, I was working on building moz to
isolate bug 121397.  However, that bug seems to have been fixed in the latest
nightlies.

In light of this I probably won't be taking the time to pull and build older
versions of moz anymore, so I won't be able to look into this bug on the side.

Can the reporter please check to see if this problem still exists in the latest
builds?
I still see this on W2K using build 2002022503
-> definitively *no* dupe of bug 121397.

Just a thought.  Reporter, what setting do you have for the cookie-acceptance 
pref?  In particular, is it set to originating-server-only?  If so, this could 
be the same as bug 134203.
Status: NEW → ASSIGNED
Cookie acceptance is set to "Enable all cookies". 
I was suspecting (hoping) this could be related to bug 134203, too, but it tried
2002040903 (which should already have picked up the fix for that bug) and this
bug (121355) is still here.
BTW: morse, did you get my mail with username/pwd for testing?
> BTW: morse, did you get my mail with username/pwd for testing?

Yes I did.  But since this bug is neither nsbeta1 nor adt, I won't be looking at 
it for quite a while.  If you want to escalate things, then nominate it.
Nominating adt1.0.0 and nsbeta1.
Rationale: This is a regression since Netscape 6.2.x/Mozilla 0.9.5, the paid
content of the page is not reachable using any newer build, and there is no
workaround available.
The site itself is the online-version of a weekly news-magazine read in parts of
northern Italy and Austria.
Keywords: adt1.0.0, nsbeta1
Nav triage team needs info:  Is this a top 100 site, or can this problem be
reproduced on any top 100 site?  Could this be an evangelism problem?  cc
Evelyn, Jaime for input.
Keywords: adt1.0.0
Whiteboard: [need info]
> Nav triage team needs info:
>  Is this a top 100 site,
No.

> or can this problem be reproduced on any top 100 site?
I would not know. 

> Could this be an evangelism problem?
Since the website worked with Netscape 6.0-6.2.2 (everything based on Mozilla
before 0.9.6), I guess that it is not the website that is broken.

Evangelizing website changes because of our own bugs is a little embarrassing
(if we have to admit why we do so) and does not seem like a good way to get
Mozilla/Netscape treaded as an equivalent browser. But if that is the way to go
for now, I can find out contact information.

Here is the contact information:

Content providers, i.e. the magazine people: info@ff-bz.com
Site designers/programmers: http://www.web.by.com/, email: info@web.by.com
I have analyzed this and now have a very simplified test case.

To run the test case, start by bringing up spm1.htm in your browser.  It will 
bring up spm2.htm which which sets some cookies and has a login button.  Press 
that button and you get to spm3.htm which should display the cookies.  The 
cookies are not being displayed.  Run the same test on nav4 and the cookies will 
be displayed.

The problem has to do with the slash in the query string, and I'll say more 
about that shortly, just as soon as I check on something.

======= FILE spm1.htm ================

<html>
  <head>
    <script>
      function login() {
        document.location = 'spm2.htm?x=/y';
      }
    </script>
  </head>

  <body onload="login();">
    Hello World #1
  </body>
</html>

========== FILE spm2.htm ===================

<html>
  <head>
    <script language="javascript">
      document.cookie = "name=myname";
      document.cookie = "pswd=mypassword";

      function login() {
        document.location = 'spm3.htm';
      }
    </script>
  </head>
  <body>
    <form>
      <input type="button" value="login" onclick="javascript:login();">
    </form>
  </body>
</html>

============ FILE spm3.htm ===============

<html>
  <head>
    <script>
      alert("cookies = " + document.cookie);
    </script>
  </head>
  <body>
    Hello World #2
  </body>
</html>

This one is awfully familiar which is why I wanted to check something, as I said 
above.  However I can't find the reference that I'm looking for.  cc'ing darin 
because he might recall.

The problem is the unquoted slash in the query string.  Because of that slash, 
the url parsing is reporting the path as being spm2.htm?x=/ in the above 
example, whereas is should actually be null (there is no pathname preceding the 
filename).  And this incorrect reporting of the path is making the cookie 
testing fail because it looks like the two files are not on the same path and 
hence can't share cookies.

If the slash were not in the query string (or if it were there but quoted), this 
example would work fine.

darin, there was another bug that was fixed recently involving unquoted slashes 
in query string but I can't find it.  Do you recall which one it was?  I don't 
recall if we closed it out as invalid, or if we actually put in a patch for it.  
If the latter, that patch might be what is breaking things here.
BTW, I should mention that the problem is on the site.  A query string may not 
contain unquoted slash characters.  I believe that was all spelled out in the 
bug report that I can't locate.
Thanks Steve.  nsbeta1-, should we give this to evangelism?
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [need info]
Not so quickly.  There still an unanswered question here which I want to better 
understand before passing this off.  It might be that I fix we made recently 
caused a regression.  I won't know until I find that other bug report.
Thank you, Steve. I guess you don't mean bug 91922 (improper handling of %2F in
query string on Windows), do you?

Mozilla's behavior in this matter changed between the 0.9.5 and the 0.9.6
release from accepting to not accepting the slash any more (as if I had never
written this before). I could verify this with your testcase.
Unfortunately, my tries to find something useful about this in bugzilla were not
successful so far.
OS: Windows 2000 → All
No, that's not the bug report I had in mind.  I wasn't aware of that one and, in 
fact, it seems to be just the opposite problem.  In that case the slash in the 
query string was properly escaped and the escaping caused problems.  The report 
that I'm thinking of caused problems because the slash was not escaped, which is 
exactly what is happening in this report.  And the report I'm thinking of 
involved cookies.

I'm very frustrated in not being able to find it because I looked into it just 
recently and I know it had the answers we are looking for.  If you can locate 
it, it would be very helpful.
Aha -- I found it.  It's bug 62348.  And it even has a patch in it.

Even though the error is on the websites, it would be easier to make the browser 
more tolerant rather than consider this as an evangelism issue.  Especially 
since that bug report already has a patch in it.  There will probably be many 
sites that we are going to fail on because of this.

Therefore I'm going to recommend that bug 62348 be considered for nsbeta1.

*** This bug has been marked as a duplicate of 62348 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: