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)

Product:
Toolkit
Component:
UI Widgets
Platform:
x86
All
Type:
defect

Tracking

()

Status:
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
Please can you provide us with a login name and password.
username = jstudent
password = rctest01 (that's zero one at the end)
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.
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?
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.
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.
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
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?
URL: https://myrc.roanoke.edu
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.
Potential dup: bug 264233
*** Bug 264233 has been marked as a duplicate of this bug. ***
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
It's broken!
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.


I believe this bug overlaps with Bug# 266274 and Bug# 264466. Some of these
should probably be marked as duplicates.
(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?
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!
*** Bug 266274 has been marked as a duplicate of this bug. ***
*** Bug 268788 has been marked as a duplicate of this bug. ***
(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.
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.
*** Bug 269494 has been marked as a duplicate of this bug. ***
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?
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.
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?
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.
i'm perplexed at what IE does to muddle its way around this.
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.
*** Bug 272378 has been marked as a duplicate of this bug. ***
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/).
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.
(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.
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
This bug also breaks sites using Interchange (http://icdevgroup.org), but only
if there isn't a /favicon.ico on the site.
*** Bug 276557 has been marked as a duplicate of this bug. ***
*** Bug 279905 has been marked as a duplicate of this bug. ***
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.
(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
vlad, per comment 19, do you remember what the fix here might be?
Flags: blocking-firefox3?
Not a blocker, IMO, but it'd be nice to work around sites that hit this...
Flags: blocking-firefox3? → blocking-firefox3-
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.
Component: General → XUL Widgets
Flags: blocking-firefox3-
Product: Firefox → Toolkit
QA Contact: general → xul.widgets

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 → --
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.