Closed
Bug 263057
Opened 20 years ago
Closed 1 year ago
favicon.ico request without cookie, saving returned cookie, breaks sessions
Categories
(Toolkit :: UI Widgets, defect)
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: cadillon, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 The site stores a cookie for the session id. I checked and that cookie is there. However, when a user logs into the system, after being logged in properly when they click on anything else in the portal such as another tab they are automatically logged out. Reproducible: Always Steps to Reproduce: 1.Go to https://myrc.roanoke.edu 2.Log In 3.Click on the "Academics" tab Actual Results: I was logged out of the system and taken to the Guest login layout. Expected Results: I should've been shown the contents of the "Academics" tab. This system worked in previous Firefox builds and still works with Mozilla
Comment 1•20 years ago
|
||
Please can you provide us with a login name and password.
Reporter | ||
Comment 2•20 years ago
|
||
username = jstudent password = rctest01 (that's zero one at the end)
Comment 3•20 years ago
|
||
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041004 Firefox/0.10.1 This site uses cookies to rember the JSESSIONID. I gess that is used to remember who the loged on user is. Please ensure that you have not disabled cookies in FireFox.
Reporter | ||
Comment 4•20 years ago
|
||
That was the first thing I checked, cookies are enabled and the cookie is present. Where you able to get 1.0PR to work with this site on your machine and it's a problem with our machine configurations?
Comment 5•20 years ago
|
||
Watching the transactions with Live HTTP Headers, I can see the problem, and probably the solution: we request /favicon.ico without the cookie, and you reply with a HTTP 200 and the text "You are looking at error.jsp. If an exception had been thrown in one of the .jsp files, this page will be loaded and the stack trace will be logged." rather than either an .ico or an HTTP 404 that would stop us from asking again. So, we keep asking, without the cookie, even after logging in, and each time we ask, you send us a new non-icon and a new guest cookie. Give us either a real icon, or a real 404, on the very first page view before logging in, and we probably won't ask again and get re-guested.
Reporter | ||
Comment 6•20 years ago
|
||
OK, I put a favicon.ico in the webapps/portal/ directory and it is still doing the same thing. We have never had a favicon and this site has worked with previous versions.
Reporter | ||
Comment 7•20 years ago
|
||
I put the icon directly in the webapps directory instead of in the webapps/portal/ directory and it worked. Thanks for everyone's help. I think that there may be other sites that will be experience the same problem though.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 8•20 years ago
|
||
Reopening: it's great that we no longer break your site, but FIXED means we fixed our bug, and I don't think we're even sure what it is yet. cc'ing Vlad, since I think he redid favicon handling recently. Vlad, what we are doing is requesting favicon.ico every page load when we don't like the response (an HTTP 200 text/html), and since we don't send our cookie with the request, but do save the cookie from the response, breaking session management. Should we be sending our cookie on the request, or throwing the one we get back from favicon.ico on the floor, or what?
Status: RESOLVED → UNCONFIRMED
OS: Linux → All
Resolution: FIXED → ---
Summary: single sign on system, users are able to login, but when they click on anything within the site, they are automaticalled logged out → favicon.ico request without cookie, saving returned cookie, breaks sessions
The problem here is that the cookie is set with a path of "/portal" -- when firefox requests /favicon.ico, we don't send the cookie because it's not within the path. However, I can't duplicate the bug -- with Firefox 0.10.1, I'm able to log in with the test account and click on Academics, etc. Oh, and I just read comment #7, which explains why I can't duplicate it :) Now, I'm not exactly sure why that fixed it, because we're still requesting /favicon.ico, but i'll set up a test server myself so I can try to break various things.
Comment 10•20 years ago
|
||
Potential dup: bug 264233
Comment 11•20 years ago
|
||
*** Bug 264233 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 12•20 years ago
|
||
I can break it again if you'd like. Most of our users are using IE (unfortunately :c)
(In reply to comment #12) > I can break it again if you'd like. Most of our users are using IE > (unfortunately :c) That would actually be very helpful, if you wouldn't mind :)
Assignee: firefox → vladimir
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Reporter | ||
Comment 14•20 years ago
|
||
It's broken!
Comment 15•20 years ago
|
||
I'm so glad I found this bug, it's the exact bug I wanted to report. It's hitting me in two distinct places, and I'll explain them. 1) my bank. after i log in successfully, the very next click tells me i have a cookie problem. bank is us.hsbc.com. I can't give you a login to use ;-) 2) my companies web application. i can explain this in detail. for this app, the actual login page is /something/login when a user requests a url outside the namespace of the app (i.e. /favicon.ico) we send them to the login page, assuming they have mistyped. the request for the login page clears cookies. bang. dead. so what happens is you login, get a session cookie, then the browser requests /favicon.ico, gets sent to the login page, and clears the cookie. I don't think a request for an icon should be able to set cookies in the browser session.
Comment 16•20 years ago
|
||
I believe this bug overlaps with Bug# 266274 and Bug# 264466. Some of these should probably be marked as duplicates.
Comment 17•20 years ago
|
||
(In reply to comment #16) > I believe this bug overlaps with Bug# 266274 and Bug# 264466. Some of these > should probably be marked as duplicates. Certainly looks like it. I have just tested real 1.0 on the US HSBC site and confirmed that the undesirable behavior is unchanged. Setting browser.chrome.favicons = false is an effective workaround, but one not likely to occur to the average new user who finds 1.0 won't work with his or her bank site! Can we get some action on this for 1.1?
Reporter | ||
Comment 18•20 years ago
|
||
I can't keep MyRC broken much longer for testing. With the new resease, I found that apparently more students, faculty, and staff that I had originally thought are using Firefox. Since the bug wasn't fixed with the 1.0 release my IT Director wants a timeframe.
(In reply to comment #18) > I can't keep MyRC broken much longer for testing. With the new resease, I found > that apparently more students, faculty, and staff that I had originally thought > are using Firefox. Since the bug wasn't fixed with the 1.0 release my IT > Director wants a timeframe. Sorry Aleah, I meant to send you mail -- go ahead and un-break the site; I set up a local test case a few days ago, unfortunately it's going to be a bit painful to fix. I'll try to get it in for whenever the next minor firefox release is (1.0.1). Thanks for letting me test with your site!
Comment 20•20 years ago
|
||
*** Bug 266274 has been marked as a duplicate of this bug. ***
Comment 21•20 years ago
|
||
*** Bug 268788 has been marked as a duplicate of this bug. ***
Comment 22•20 years ago
|
||
(In reply to comment #21) > *** Bug 268788 has been marked as a duplicate of this bug. *** Would you or James consider marking Bug# 264466 a duplicate as well, I'd do it myself but I've not been so empowered.
Comment 23•20 years ago
|
||
Nope, bug 264466 is about one person who couldn't log into US Bank's site, and another who could (note that I wasn't disabling browser.chrome.favicon to get in). All the rest of it, people piling on with other sites, was just morphing noise.
Comment 24•20 years ago
|
||
*** Bug 269494 has been marked as a duplicate of this bug. ***
Comment 25•20 years ago
|
||
I fail to see how this is a bug. if /favicon.ico is outside the path of the cookie, what are we doing wrong in not sending a cookie? What would be the fix here?
Comment 26•20 years ago
|
||
i have same problem with squirrelmail and firefox, when favicon.ico doesn't exists firefox doesn't send session Cookie and so i go into logged-out state. When favicon.ico exists, everything works ok.
Comment 27•20 years ago
|
||
i agree with mvl... if your session cookie paths don't include root, then it's correct for a /favicon.ico request to not include those cookies. if this causes the server to permanently drop the session and issue a new one, then we need to (a) fix the site, or (b) not request /favicon.ico. if it just causes an additional guest session to be created, and there's no harm in that, then we can just ignore the set-cookie requests that come back from that request. could favicon code strip out those cookie headers before nsHttpChannel goes about processing them?
Comment 28•20 years ago
|
||
Not accepting cookies from favicon would fix what is described in comment 15, because the cookie won't get cleared anymore. I'm not sure if it will fix all problems. Some sites might do other things that cause problems.
Comment 29•20 years ago
|
||
i'm perplexed at what IE does to muddle its way around this.
Comment 30•20 years ago
|
||
I'm surprised a request for /favicon.ico can clear a cookie. The cookie is not set in that path, so how can it be deleted from there? A public testcase would help.
Comment 31•20 years ago
|
||
*** Bug 272378 has been marked as a duplicate of this bug. ***
Comment 32•20 years ago
|
||
There's a public testcase for you, until they fix it: go to www.wamu.com and pretend to sign up for Personal online banking: all your repeated requests for favicon.ico are redirected to /logon/logon.asp, where you get a new set of session cookies (which aren't set with a path, but could be, and would then clear/replace cookies with path=/logon/).
Comment 33•20 years ago
|
||
So maybe the fix would be to not allow redirects for favicon.ico requests? We should test if that is what IE does, or if doesn't allow cookies from favicon.ico.
Comment 34•20 years ago
|
||
(In reply to comment #33) > So maybe the fix would be to not allow redirects for favicon.ico requests? It doesn't look as good idea for me.
Comment 35•20 years ago
|
||
Why not? Like i said, we need to figure out what IE does, and not allowing redirects can be it, instead of some cookie trick
Comment 36•20 years ago
|
||
This bug also breaks sites using Interchange (http://icdevgroup.org), but only if there isn't a /favicon.ico on the site.
Comment 37•20 years ago
|
||
*** Bug 276557 has been marked as a duplicate of this bug. ***
Comment 38•20 years ago
|
||
*** Bug 279905 has been marked as a duplicate of this bug. ***
Comment 39•20 years ago
|
||
I made a test for redirection of favicon.ico on IE. I'm not sure when IE requests the icon, but i got it to follow the redirect. 131.211.35.234 - - [28/Jan/2005:14:17:06 +0100] "GET /favicon.ico HTTP/1.1" 301 384 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Win 9x 4.90; Q312461)" 131.211.35.234 - - [28/Jan/2005:14:17:06 +0100] "GET /favicon2.ico HTTP/1.1" 200 1406 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Win 9x 4.90; Q312461)" So disallowing that wouldn't be the solutionn.
Comment 40•19 years ago
|
||
(In reply to comment #39) > I made a test for redirection of favicon.ico on IE. I'm not sure when IE > requests the icon, It looks to me as if IE doesn't get new favicons when changing pages at all, only when a specific page is bookmarked. Is this the critical difference, not important, or just flat-out wrong on my part? :-)
Assignee: vladimir → nobody
Status: ASSIGNED → NEW
Comment 41•17 years ago
|
||
vlad, per comment 19, do you remember what the fix here might be?
Updated•17 years ago
|
Flags: blocking-firefox3?
Comment 42•17 years ago
|
||
Not a blocker, IMO, but it'd be nice to work around sites that hit this...
Flags: blocking-firefox3? → blocking-firefox3-
Comment 43•16 years ago
|
||
i'm currently looking at a fix for this, but need more data. a simple question is - should favicon requests be allowed to get and set cookies? we could ban them from doing so, which might solve the particular issues reported here, but may create new ones. does anyone know if sites expect cookies from these requests? does IE send and accept cookies from favicon requests? technically, i'm not yet sure how we'd implement that. the code that kicks off the load request from XUL (see browser.js::PageProxySetIcon()) is pretty high-level; i don't know of a way to communicate load flags etc to the channel. a more drastic option would be to ban all cookie requests without a parenting content window in the cookieservice itself. (i.e., anything that didn't originate, at some point, from within a content docshell - this would affect cookies over e.g. safebrowsing too.) if we did this, we'd have to abstract it into an overrideable implementation so embeddors can change it.
Updated•15 years ago
|
Component: General → XUL Widgets
Flags: blocking-firefox3-
Product: Firefox → Toolkit
QA Contact: general → xul.widgets
Comment 44•1 year ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Severity: major → --
Updated•1 year ago
|
Status: NEW → RESOLVED
Closed: 20 years ago → 1 year ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•