Closed Bug 758134 Opened 14 years ago Closed 14 years ago

FF forgets username and password

Categories

(Core :: General, defect)

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED INVALID

People

(Reporter: anfrage, Unassigned)

References

()

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0 Build ID: 20120516113045 Steps to reproduce: Click on a link to an external video, for which one has to login with user name and password. Testcase: http://www.in-tanz.de/test-ff/extern-passwort.html Actual results: You are always pushed back to the free video in the public area. User name and password are dropped, and you will be thrown out of the protected area. Expected results: - You should be logged in, - User name and password should be remembered by FF, - The full (internal) video should be shown. This worked properly at least till late summer 2011 with Firefox. Now, it only works with other browsers (for example Chrome, Safari)
Severity: normal → major
Priority: -- → P3
It works if you either enter the direct URL in the URL bar or disable the referer header ( network.http.sendRefererHeader=0 ) It fails if you use the flash button that opens a new tab with the video and the referer header is enabled. I have tested with Firefox12, Seamonkey trunk and Opera11.6 (!) and they all fail. I think that this used to work because we had a bug and never send a referer from Plugins but we fixed that last year. I'll attach 2 cookie logs, one from a failed try and the other one from a successful login where I disabled the HTTP referer. The login Cookie seems to be associated with the "GTD" cookie. In the failing cookie log you can see that the page is changing the value of the cookie in the middle while it doesn't do that in the successful login. failing: 0[160f140]: ===== COOKIE ACCEPTED ===== 0[160f140]: request URL: http://www.getthedance.com/user/login 0[160f140]: cookie string: GTD=9tpqihtcequkoin657n8kts5p2; expires=Thu, 31 May 2012 17:09:46 GMT; path=/ 0[160f140]: replaces existing cookie: true 0[160f140]: current time: Thu May 24 17:09:47 2012 GMT and later the ID changed: 0[160f140]: ===== COOKIE ACCEPTED ===== 0[160f140]: request URL: http://www.getthedance.com/course/video/discofox-stufe-3-spot-turn-in-schattenposition-1 0[160f140]: cookie string: GTD=dovc7a2ov8qve220i57su7qkc5; expires=Thu, 31 May 2012 17:09:47 GMT; path=/ 0[160f140]: replaces existing cookie: true 0[160f140]: current time: Thu May 24 17:09:48 2012 GMT Reporter: Is the Domain getthedance.com your Domain ? Why is the page changing the cookie value if the referer from your flash page is sent with the request ? This looks like a bug in the page. Anyway, could someone else please compare the http referer between Webkit and Gecko ?
Status: UNCONFIRMED → NEW
Component: Untriaged → Plug-ins
Ever confirmed: true
Priority: P3 → --
Product: Firefox → Core
QA Contact: untriaged → plugins
Version: 13 Branch → Trunk
This is not caused by the plugin referer. You get the same behavior with a HTML link: http://matti.no-ip.org/bug758134/test.html IE9 fails as well if you use this html testcase ! BTW: This is the request initiated by the reporters URL that shows the referer header http request [ GET /course/video/discofox-stufe-3-spot-turn-in-schattenposition-1 HTTP/1.1 Host: www.getthedance.com User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20100101 Firefox/12.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Referer: http://www.in-tanz.de/test-ff/extern-passwort.html ] I'm now pretty sure that this bug report is invalid.
Component: Plug-ins → General
QA Contact: plugins → general
> Reporter: Is the Domain getthedance.com your Domain ? No, I just link to it quite often, since it has a lot of usefull videos > Why is the page changing the cookie value if the referer from your flash > page is sent with the request ? Sorry, I do not know.
Thank you for testing the reported problem and your results. Still, sorry, I cannot follow neither the logic of this discussion nor the resulting judgement. a) Firefox versions up to summer 2011 could easily cope with this problem. b) Other browsers like Chrome and Safari still can. c) Referring to Internet-Explorer 9: You will always be able to find browsers, which are in some special respect as bad as, or even worse than Firefox. Such comparisons to a browser with similar problems should not be the basis for a judgement. Having been a lecturer for software / internet at a university for many years, I quite surely know, that for two decades all successful browser developers tried to cope with user problems within their browser. The main reason for supporting free software and Firefox in the beginning was the monopoly of Microsoft, a company that denounced any bug, they did not want to care for, a user problem. Firefox cared for this problem till summer 2011, others like Chrome and Safari still do. Thus the new versions of Firefox fall behind the capabilities of prior versions and browsers from other developers. So, I am afraid I have to call this new feature of Firefox a bug.
>a) Firefox versions up to summer 2011 could easily cope with this problem. I first thought that this was caused by the http referer that we now send from flash requests but that is not true. This also fails with a Firefox build from 2010-08-07. What tells you that ? The site seems to have changed. >b) Other browsers like Chrome and Safari still can. That is one browser engine called webkit. It fails with Gecko (Firefox, Seamonkey), Opera and for the html link also with IE9 Please let the politics out of this bug, that doesn't belong into a bug report. I investigated the issue and this is a site bug. I could tell you why this works in webkit but I refuse to install any webkit based browser on my systems. That it works in webkit is most likely a bug in webkit. You may want to report a bug to them. Please contact the site owner and ask why the page fails if the request is done with a third party http referer. marking invalid as this can't be fixed in the browser.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
btw: You can give them the URL to this bug report
and one last comment: >Please let the politics out of this bug, that doesn't belong into a bug report. This wasn't meant to be rude but what do you think that we should do ? We are doing everything right as far as I can see and according to the specifications. This specifications are the technical rules for the internet called RFCs (http://de.wikipedia.org/wiki/Request_for_Comments) and this rules are valid for every software that interacts with the internet.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: