Closed
Bug 27687
Opened 25 years ago
Closed 24 years ago
I can no longer log into my yahoo mail account
Categories
(Other Applications :: ChatZilla, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: gregk72, Assigned: morse)
References
()
Details
(Whiteboard: [rtm++])
Attachments
(3 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
From versions M9->M12 I was able to read my yahoo mail from Mozilla. Since M13 and beyond, I can no longer get past the yahoo mail login screen. It seems to go into a loop when it goes to bring up the initial yahoo mail page. I get transfering data from login.yahoo.com, then transfering data from f1.mail.yahoo.com, and it keeps cycling between the two before landing me back at the login page. As I said, this was working from M9->M12 and it works fine in Communicator 4.7 and IE5.
Two more things: 1) it does work with the Linux M13 release 2) I tried closing Communicator, moving my Plugins directory to the recycle bin, made sure I did not have any Plugins in my Mozilla bin/ directory, but that didn't help.
Comment 2•25 years ago
|
||
This worksforme on 2000021608 WinNT 4 SP6. I suspect that this was probably due to one of the cookie bugs which has since been cleared up. gregk72@yahoo.com: Could you try a nightly build and see if this is still occuring? If not, please mark this workforme...
I am using build id: 2000021509 I tried removing all my yahoo cookies first since you mentioned it might be a cookie problem. I still cannot log into yahoo mail.
It seems to only happen when I convert my Communicator 4.7 profile. If I create a fresh profile from scratch, then I am able to login to yahoo mail. Therefore it sounds like there might be a bug when cookies are moved over from Communicator to Mozilla.
I am using build id: 2000021708 It works when I create a brand new profile from scratch It does not work with my converted communicator profile, even if I remove all the .yahoo and mail.yahoo.com cookies.
Assignee: leger → morse
Component: Browser-General → Cookies
QA Contact: cbegle → tever
Assignee | ||
Comment 6•25 years ago
|
||
From the description given here, this has got to be something very specific to your particular 4.7 profile. So I won't be able to reproduce it either. Can you try stripping down your 4.7 profile to its bare essentials so that it still demonstrates the problem. At that point it might be obvious where the offender is. Since you aren't migrating cookies and presumably aren't saving the login with single-signon (you didn't mention that in this report), this is not really my domain. But I'll be glad to look at it if you can get the absolute-minimum profile and attach it to this report (or e-mail it to me if you prefer). One other thought just occured to me. Do you have a cookperm.txt file in your 5.0 profile? If so, could it be the case that you are automatically rejecting cookies from yahoo specifically and that is why you are not getting in. This would be consistent with your comment about it working fine with a new profile (which of course wouldn't have the cookperm.txt file) but not with an existing one.
I was able to create a new 4.7 profile and just create the yahoo cookies, convert that to mozilla, and was able to login to yahoo mail. Must have something really strange in my old 4.7 profile. I will have to figure that out at some point. Thanks! :)
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
One more comment... I just took my original 4.7 profile and paired down my cookies.txt (I guess it has been awhile since I have gotten around to pruning it). I removed my Users50 folder and removed mozregistry.dat and re-started with ProfileManager to re-create my mozilla profile. Now it DOES work and I can log into my yahoo mail. Thanks for the help! :)
Assignee | ||
Comment 9•25 years ago
|
||
See bug 28545 which sounds like the same sort of problem as reported here.
Reporter | ||
Comment 11•25 years ago
|
||
it seems inconsistent... if I d/l a new version of mozilla it sometimes works, sometimes not. recently not.. currently running version 2000022208. I think there is still a major bug here when transferring 4.7x profiles to mozilla and I think it should be fixed before netscape creates their beta version.
Status: RESOLVED → REOPENED
Component: Cookies → Profile Migration
Resolution: FIXED → ---
Assignee | ||
Comment 12•25 years ago
|
||
If you still have a problem, then take your profile and try to pare it down to the bare minimum that still demonstrates the problem. Then attach that minimized profile to this report. Only then can we possibly try to solve the problem. Since you now believe the problem has to do with profile migration, I'm reassigning to the owner of that module.
Assignee: morse → dbragg
Status: REOPENED → NEW
QA Contact: tever → gbush
Comment 13•25 years ago
|
||
The only "migration" that happens to the cookie file is that it is copied. That's it. It's not "read" or "translated" in any way. I don't believe this is a migration issue but just to make sure I need you to run a little test: 1. Run Mozilla's profile migration routine 2. After the migration is completed and BEFORE doing anything in Mozilla, copy the cookie file to some safe place. 3. Compare the saved cookie file to the one in your original 4.7 profile directory. They should compare exactly. If they don't, would you please list in the bug where they differ? Thanks.
Reporter | ||
Comment 14•25 years ago
|
||
In 2000022408 I can't even get to the yahoo mail login screen! Also, if I remove my .yahoo.com cookies, then I can't even log into the main my.yahoo.com page! I checked my cookies.txt, prefs.js and libprefs.js and a few entries were added to prefs.js during migration, but nothing that looked like it should affect this. I think this should be re-assigned back as a cookie problem. Also most of the M14 nightlies that I have tried have not touched cookiesperm.txt (i.e. clicking on remember this decision isn't doing anything) [gak@teraknor gak]$ diff prefs.js //c/Program\ Files/Netscape/Users/gak/prefs.js > tt [gak@teraknor gak]$ less tt 1,2c1,2 < # Mozilla User Preferences < // This is a generated file! --- > // Netscape User Preferences > // This is a generated file! Do not edit. 10d9 < user_pref("browser.startup.homepage_override.1", false); 57d55 < user_pref("mail.directory", "E:\\MozillaTest\\Users50\\gak\\Mail"); 98a97 > user_pref("mailnews.reuse_thread_window2", true); 106d104 < user_pref("news.directory", "E:\\MozillaTest\\Users50\\gak\\News"); 116,118d113 < user_pref("prefs.converted-to-utf8", true); < user_pref("premigration.mail.directory", "C:\\Program Files\\Netscape\\Users\\gak\\Mail"); < user_pref("premigration.news.directory", "C:\\Program Files\\Netscape\\Users\\gak\\News"); 125,126d119 < user_pref("timebomb.first_launch_time", "951433488916000"); < user_pref("xpinstall.notifications.lastDate", 951433490);
Component: Profile Migration → Cookies
Assignee | ||
Comment 15•25 years ago
|
||
SOme of the stuff that you are reporting today is probably due to the regression that norris' checkin caused. Either pull his later fix, or wait until tomorrow's build to see if things get back to the way they used to be.
Reporter | ||
Comment 17•25 years ago
|
||
just tried 2000022716 and still cannot log into yahoo mail from my converted 4.7 account. I have only 10 cookies in my cookies.txt (bugzilla, yahoo, nytimes, deja, and slashdot). It only works if my 4.7 profile has no cookies, or I create a new mozilla profile. My guess is that something about the way the cookies are stored in the file (eol charaters, tabs, or ?) has changed between 4.7 and Mozilla and thus Mozilla isn't able to correctly update these 4.7 cookies.
Reporter | ||
Comment 18•25 years ago
|
||
just tried one more thing... copied a cookies.txt from a fresh mozilla profile to my converted profile. It still didn't work... then I noticed that the fresh profile has "Accept all cookies" set, my profile has "Accept only sent back through originating server". When I set my converted profile to the same cookie setting, it works!
Comment 19•25 years ago
|
||
I'm reassigning this back to you Steve since Greg's tests point to cookie management rather than migration.
Assignee: dbragg → morse
Reporter | ||
Comment 20•25 years ago
|
||
When I am actually logged into yahoo mail, it creates a cookies from the server mail.yahoo.com (which only exists though the session). All the other yahoo cookies are .yahoo.com. This might be a clue as to what the problem is. When I had "Accept only from originating server" was it possible that this cookie could not be created?
Assignee | ||
Comment 21•25 years ago
|
||
It looks like Greg has already solved the problem -- it's his pref setting. Apparently you need to send foreign cookies in order for yahoo mail to work. So basically this bug report is invalid. There is a slight difference in the way 4.x and seamonkey treat the foreign-cookie pref. Let me explain: Cookies go in two directions: a site sends cookie-setting requests to the browser as part of its http response, and the browser sends cookies to the site when it make an http request. The foreign-cookie pref in 4.x affects the setting of cookies only -- foreign cookies will still get transmitted to the site regardless of the pref setting. The latter could lead to a privacy attack whereby a user set the pref after the fact (some foreign cookies already got set) and the client is continuing to send those cookies back to the site in spite of the change in setting. So this loophole was closed in seamonkey. It may be that you can still log onto your yahoo mail account with 4.x and the same cookie file, even though you have the no-foreign-cookie pref turned on. That's because you already collected those cookies in 4.x before you turned on the pref. I'm sure that if threw away your cookie file in 4.x and then tried to log onto yahoo mail with the no-foreign-cookie pref on, you won't be able to. Let me know if you disagree with my analysis or if I wasn't clear in what I was saying.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Assignee | ||
Comment 22•25 years ago
|
||
Had a mid-air collision so my response above was written before I saw Greg's latest posting. If with the pref set to no-foreign-cookies in 4.x, are you able to log onto yahoo mail. If so, then it's because of old cookies that were set prior to your turning on the pref. If not (i.e., the behavior is identical to seamonkey), then it's because of what you just said -- yahoo mail is unable to set the foreign cookie.
Assignee | ||
Comment 23•25 years ago
|
||
There's a quirk here. I just closed this bug report out as resolved-invalid, yet all I'm seeing in the report now is "Status: Resolved". The "Resolution:" field is blank. I'm going to try to make it invalid once again and if that fails I'll notify Terry of the problem.
Status: RESOLVED → REOPENED
Assignee | ||
Comment 24•25 years ago
|
||
Continuing in my attempts to get the invalid indicator to appear.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → INVALID
Assignee | ||
Comment 29•25 years ago
|
||
Since this bug keeps getting reported so many times, I decided to send the following message to Yahoo customer support. Let's see if there's any follow-up on their part. "I'm with Netscape Commucations and and responsible for the cookies work in our browser development. We are constantly getting bug reports about our browser being unable to logon to yahoo mail. For details see: http://bugzilla.mozilla.org/show_bug.cgi?id=27687 The problem is invariably that the user had set his browser options to reject cookies that do not get sent back to the originating site (known as third-party cookies). It appears that yahoo makes use of such cookies and therefore doesn't allow the user to logon when third-party cookies are not returned to yahoo. But, unfortunately, the user does not get any indication of why the login was refused and instinctively assumes it was a browser bug. It would be extremely helpful to both Yahoo and Netscape if you could put up a message telling the user that why his logon was refused and telling him how to remedy the situation (change his pref setting). You can determine this quite easily since you will receive back the first-party cookies that you set but not the third-party cookies."
Assignee | ||
Comment 30•25 years ago
|
||
I must have been high on something to think that I would actually get cooperation from yahoo. Here is a copy of the response that I received to my message: ***************** Thank you for contacting Yahoo! Customer Care. We realize that this email is lengthy, but please read the entire message below, as your answer may be included. Within this email, you will find information on how to: I. UPDATE YOUR ALTERNATE EMAIL ADDRESS II. SEARCH FOR YOUR YAHOO! ID (if you forgot it) III. REQUEST A NEW PASSWORD (if you forgot it, or it is not working) IV. CHANGE YOUR PASSWORD (you must know your current password first) V. UPDATE YOUR PASSWORD QUESTION AND SECRET ANSWER VI. REMOVE YOUR YAHOO! ACCOUNT ------------------------------------------------------------------------ ---- I. UPDATE YOUR ALTERNATE EMAIL ADDRESS: 1. Go to any of Yahoo!'s personalized properties (such as Yahoo! Chat, Yahoo! Games, My Yahoo!, etc.) and sign in. **** 2. In the top right hand corner, click on "Account Info." 3. Click on "edit" next to the member information portion of this page. 4. This screen will allow you to change your alternate email address and choose which address you would like for your primary email. This simply means that this address is the one where you will receive all your confirmation messages if you ever request a new password. If you have signed up to receive special offers from Yahoo!, this is also where you would receive these promotions. 5. Please make sure to click the "finish" button after you have edited any information. **** For account users who want to change their alternate email via Yahoo! Mail, follow these instructions: 1. Log into your Yahoo! Mail account using your current password. 2. Click the "Options" link on the left-hand navigation bar. 3. Choose the "Account Information" link on this screen and continue with steps #3, #4, and #5 above. If you do not find your answer in this email, however, you may reply if you wish. If you choose to do so, be sure to include the following information. Without all of the following information, we will be unable to process your request. 1. Yahoo! ID/Yahoo! GeoCities ID 2. ZIP Code you included when you registered for this account (Non-U.S. residents, please include Country) 3. Birth date you included when you registered for this account 4. Alternate email address that we currently list 5. Your new alternate email address (Please note, this cannot be an "@yahoo.com" address) 6. Secret Question and Answer (if applicable). --------------------------------- II. SEARCH FOR YOUR YAHOO! ID (if you forgot it): 1. Return to the Sign In page: <http://edit.yahoo.com> 2. Click the "Get Help Signing In" link 3. Click the "Yahoo! ID Search" link 4. This page will ask for the birthday, alternate email address, and ZIP Code that you included when you registered for the account. 5. Note: If you're using Yahoo! Mail, your Yahoo! ID is the first part of your address. For example, if your Yahoo! Mail address is "person@yahoo.com", then your Yahoo! ID is "person". ------------------ III. REQUEST A NEW PASSWORD (if you forgot it, or it is not working) If you are having trouble with your password, the following are the most common reasons your password might not be accepted by the system: 1. Passwords are case sensitive. Please check the Caps Lock key, and try logging in again. 2. Punctuation and white space are significant in your password. Please verify all punctuation. 3. The date and time on your computer are important. Please verify that they are correct. Passwords are encrypted when stored, so we are not able to tell you your old password. To get a new password: 1. Return to the Sign In page: <http://edit.yahoo.com> 2. Click the "Get Help Signing In link" 3. Click the "New Password Request" form link 4. Enter your Yahoo! ID and the birthday you included when you registered for this account 5. Click the Send Request button Your new password will automatically be sent to the alternate email address that you specified when you registered for this account. ------------------ IV. CHANGE YOUR PASSWORD (you must know your current password first): 1. Return to<http://my.yahoo.com> and Sign In, if necessary 2. Click the "Account Info" link at the top of the page 3. Click "Change Password" 4. Enter your old password (or the one we just sent) 5. Enter your new password 6. Now confirm your new password 7. Click Finished Please Note: You must know your current password to choose a new one. If you don't know your current password, see above for instructions on requesting a new one. ------------------ V. UPDATE YOUR PASSWORD QUESTION AND SECRET ANSWER To update your Password Question/Secret Answer, please forward the following information to: my-login-request@yahoo-inc.com 1. Yahoo! ID 2. ZIP Code you included when you registered for this account (Non-U.S. residents, please include Country) 3. Birthday you provided at registration 4. Your current Password Question and Secret Answer 5. The new Password Question and Secret Answer 6. Alternate email address that we currently list, if applicable Please Note: The punctuation, spelling, and spacing of your new Secret Answer are very important. We will copy the Secret Answer exactly as it appears in your email. ------------------ VI. TO REMOVE YOUR ACCOUNT If you still have your Registration Confirmation email, you can follow the instructions included on how to remove your account. If you no longer have this email, or if the removal link is not functioning, please forward ALL of the following information and include REMOVE ENTIRE ACCOUNT or REMOVE MAIL ACCOUNT ONLY in the subject line of your email: - Yahoo! ID associated with this account - Alternate email address you included during registration - Date of birth - Zip Code (International users, please include Country) Note: Removing this ID will also remove any other items associated with this ID such as aliases*, profiles, classified ads, and Yahoo! Mail addresses.*To check which aliases are associated with this account, go to http://profiles.yahoo.com and sign in with the ID you want deleted. Regards, Yahoo! Customer Care
Comment 36•24 years ago
|
||
We will get killed if we ship like this. Yahoo is extremely visible, and the "don't send to foreign hosts" option is popular. At the very least we need to release note the problem so users will know to turn off the blocking, because the yahoo site (non-)response will mystify them. Note there are at least 9 duplicates of this bug, and perhaps more if other bugs were duplicates of those first. The analysis of Communicator behavior is slightly incorrect. If I delete all my cookies and then set the "Accept only cookies that get sent back to the originating server" pref I can still log onto Yahoo. So why does Mozilla consider these cookies foreign, and Communicator doesn't?
Comment 37•24 years ago
|
||
The suggested relnote text would be something along the lines: If you are having trouble logging into yahoo.com or other sites you may be blocking required cookies. Under the Edit menu select "Preferences". On the Preferences dialog open the advanced tab and select the Cookies tab. Set the "Enable all Cookies" option. You should also press the "View stored cookies" button and select the "Cookie Sites" tab to make sure the site you are trying to access is not listed as unable to set cookies. If it is delete that entry.
Assignee | ||
Comment 38•24 years ago
|
||
They are definitely foreign cookies. And communicator consider them foreign cookies in that it didn't allow them to be set. But the bug in communicator was that if the cookie was previously set, it would still get transmitted back to the site on future visits. This was considered a security breach and is the bug that mozilla solved.
Assignee | ||
Comment 39•24 years ago
|
||
Rather than release-note it, let's look at the root cause of the problem. The problem occurs if the user does all of the following: 1. User is running 4.x and has option set to accept all cookies 2. User visits yahoo mail and collects the third-party cookie 3. Sometime later user changes pref to accept-originating-server-cookie-only 4. User continues to successfully log on to yahoo mail in 4.x 5. User later decides to migrate to seamonkey At this point the migrated profile contains the restricted cookie pref and also contains the yahoo third-party cookie. And the restricted pref is preventing the cookie from being sent back, so the user can no longer log on to yahoo. The problem is that we have a different pref in seamonkey than we had in 4.x. In 4.x the pref was "ACCEPT cookies that ..." whereas in seamonkey it is "ENABLE cookies that ...". These are not equivalentand and it is a mistake to consider them as such when doing the migration. If we didn't migrate this one pref, we owuld not have a problem with yahoo mail.
Assignee | ||
Comment 40•24 years ago
|
||
OK, if you want to re-open this, then let's assign it to profile migration to fix the problem as I described in my comment above. Reassigning.
Assignee: morse → dbragg
Status: REOPENED → NEW
Component: Cookies → Profile Migration
Assignee | ||
Comment 41•24 years ago
|
||
I'm collecting traffic and it looks like it might be a bug in seamonkey after all. Looks like we are mistakenly thinking that a cookie is a foreign cookie when it is not. Still investigatig -- more to say on this shortly.
Assignee | ||
Comment 42•24 years ago
|
||
It's definitely a cookie problem. Reassigning back to myself.
Assignee: dbragg → morse
Component: Profile Migration → Cookies
QA Contact: gbush → tever
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 43•24 years ago
|
||
I'd like to clarify the steps given to cause this problem, because users will get into this situation much more easily than that... In Mozilla: Create a new profile. Set pref to "Enable cookies for originating server only". You now can't log in to Yahoo, no migration involved. In Communicator: Create a new profile (i.e. no cookies). Set pref to "Accept only cookies sent to originating server". You can log on to Yahoo, no prior yahoo cookies required. Setting priority to P2 due to the visibility
Priority: P3 → P2
Whiteboard: [rtm need info]
Assignee | ||
Comment 44•24 years ago
|
||
I was completely wrong in the past in my analysis of the yahoo mail problem. Here is what I now believe is happening. When a site attempts to set a cookie or when a cookie is about to be sent back to a site, a test is made to see if the site is the same as the site that the user actually requested (i.e, typed in or clicked on a link to or was redirected to). The two urls are compared and if they are the same then we pass the "from originating server" test. In the case of yahoo mail, the login form is submitted (via a post) to login.yahoo.com. That site does a redirect (302) to f7.mail.yahoo.com. The browser then does an http request to f7.mail.yahoo.com but since this is not the originating server, no cookies are sent to it. One problem that I have not yet been able to sort out is why the originating server was not updated to f7.mail.yahoo.com in the case of the redirect. I thought that was how originating server test was supposed to work and I recall seeing such updating happen in the past on other sites (although I can't find any examples now). I think that the correct fix is to figure out why the redirect was not updating the originating server and make it do so. As a partial fix for the yahoo mail problem, we can simply remove the test for originating server when sending out cookies. Such a test was never done in 4.x so we would be no worse off than our old browsers were. I'll attach a patch for removing the test. But it's not clear that such a change will solve all the problems. It will solve the problem with the sending of cookies but won't there be an equivalent problem with the setting of cookies. In other words, what happens for a site that sets cookies after a redirect. Such settings should be permitted. But if the redirect is not updating the originating server, these cookies will be rejected (although they will be accepted in 4.x). Unfortunately I have not been able to find any sites that set cookies after a redirect so I can't prove that this is a real problem.
Assignee | ||
Comment 45•24 years ago
|
||
Comment 46•24 years ago
|
||
A classic problem with tightening security/privacy is that it can break existing and well intentioned applications. If this privacy feature breaks yahoo mail, then we have a Big Problem (TM). If Steve can get this all straight, and yahoo mail can work, then fine. If not, then we need something much more agressive than a release note. We might even need a link to a live Netcenter page with warning details if ever the user wanted to turn on this pref. Given where we are in the project (relative to ship date for Nav 6), we may have to even go further and disable this feature via a hidden pref, so that reading the release notes about turning this feature on would be the *ONLY* way to get into this situation. To be clear: IMO (not yet discussed with PDT), having a pref (re: 3rd party cookie blockage) that causes an unsuspecting user to disable his ability to use yahoo mail is not acceptable. Steve: Does your recent patch leave yahoo mail working even with this privacy pref set? p.s., Note that most sites already detect and diagnose client scenarios where cookies are not being set at all. As a result, I'm not concerned about the situation where the user has singled out yahoo and disabled cookies on a per-site basis.
Assignee | ||
Comment 47•24 years ago
|
||
I found an example of what I was looking for. http://www.wargames.com This site doesn't exactly do a redirect (that is, it does not send back a response with a 3xx code) but by some other means (which I don't yet understand) it manages to do a redirect to click2net.com. When visiting wargames.com with the 4.x, the following cookie to be set for domain .click2net.com whereas with seamonkey it will not (the originating-server-only pref was set in both cases). DISC=1 This demonstrates that the patch that I posted is insufficient and simply a hack that happens to make yahoo mail work. Unless we can properly update the orginating server after a redirect, we run the risk of breaking websites that worked fine in 4.x.
Assignee | ||
Comment 48•24 years ago
|
||
Yes, my patch will make yahoo mail work, even with the pref set. But as noted in my most recent comment, there may still be other sites that the pref will break. I'll look into why the cookie module did not get an updated originating server after a redirect.
Assignee | ||
Comment 49•24 years ago
|
||
Here's a real simple patch that will cause the originating-server indicator to be updated when a redirect occurs. It fixes the yahoo mail problem perfectly. However I don't know what possible consequences this might have on other things. Need some comments from networking people on this. Index: nsHTTPChannel.cpp =================================================================== RCS file: /cvsroot/mozilla/netwerk/protocol/http/src/nsHTTPChannel.cpp,v retrieving revision 1.234 diff -c -r1.234 nsHTTPChannel.cpp *** nsHTTPChannel.cpp 2000/09/22 03:44:12 1.234 --- nsHTTPChannel.cpp 2000/10/08 02:30:23 *************** *** 2541,2546 **** --- 2541,2547 ---- if (((301 == aStatusCode) || (302 == aStatusCode) || (aStatusCode == 305)) && (location)) { nsCOMPtr<nsIChannel> channel; + mURI->SetScheme(location); /* so that cookies originating-server-only pref will work */ rv = Redirect(location, getter_AddRefs(channel), aStatusCode); if (NS_FAILED(rv)) return rv;
Assignee | ||
Comment 50•24 years ago
|
||
Just for clarification, either of the two patches presented above will cause yahoo mail to work properly. The first patch is really a band-aid that disables the originating-server-only feature when sending out cookies. The second patch does not disable any feature but rather fixes the underlying problem whereby the indication of the originating server is updated whenever a redirect occurs.
Assignee | ||
Comment 51•24 years ago
|
||
Here's the story on the www.wargames.com case that I mentioned above. I said there that I didn't know how the redirect was occuring. Now I do. This example was a red herring. The site simply contains some javascript which is hosted on the click2net.com page and which sets a cookie. A simplified demo of this is: <html> <body> demo of third-party cookie getting set <script src="http://eh.click2net.com/"> </script> </body> </html> If you bring up the above page as a local file on your hard disk (or as a file on any other server), it will result in the click2net cookie getting set. Interestingly, this cookies gets set in 4.x (even when the originating-server-only pref is set) but it does not get set in seamonkey. And with either of my patches above it still does not get set. That is a good thing. This click2net site should definitely not be allowed to set the cookie when the pref is set. The fact that it was getting set in 4.x is a bug in 4.x. It could be that in seamonkey we are already breaking some archane site that is exploiting this loophole to set cookies in 4.x. But such sites deserve to be broken -- they were going out of there way to set third-party cookies. Since we haven't received any complaints about this yet, apparently no major site is doing this.
Assignee | ||
Comment 52•24 years ago
|
||
Just got a correction from valeski -- I was using SetScheme in my patch when it should have been SetSpec. Revised patch is as follows (I'll also include the patch as an attachment for convenience). Index: nsHTTPChannel.cpp =================================================================== RCS file: /cvsroot/mozilla/netwerk/protocol/http/src/nsHTTPChannel.cpp,v retrieving revision 1.234 diff -u -r1.234 nsHTTPChannel.cpp --- nsHTTPChannel.cpp 2000/09/22 03:44:12 1.234 +++ nsHTTPChannel.cpp 2000/10/08 18:16:55 @@ -2544,6 +2544,7 @@ rv = Redirect(location, getter_AddRefs(channel), aStatusCode); if (NS_FAILED(rv)) return rv; + mURI->SetSpec(location); /* so that cookies originating-server-only pref will work */ // Abort the current response... This will disconnect the consumer from // the response listener... Thus allowing the entity that follows to
Assignee | ||
Comment 53•24 years ago
|
||
Assignee | ||
Comment 54•24 years ago
|
||
Patch has been reviewed (as normal reviewer) and approved (as module owner by rpotts. r=rpotts, a=rpotts Rick is currently at home and off-line so he can't put this notation in the bug report himself but will do so when he gets on-line. Rick's comments were that the problem was that the loadgroup was keeping the orphaned default load channel (the one that preceded the redirect) and wasn't being updated when the redirect occured. He concluded that my patch, which fixed up the url in the orphaned default load channel, was the correct thing to do now for the branch (minimal risk) whereas for the tip we should eventually updating the default load channel. So he said that for now my patch should get checked into both the branch and tip and a bug opened agains networking to eventually fix this the right way on the tip. I mentioned to Rick that Judson had concerns that this change might break something else (and I shared those concerns). So Rick had me do an LXR search for GetDefaultLoadChannel. The only other place it was used was in nsImageNetContextAsync and the only fields in the default load channel that were being used there were the referrer field and the attribute field. So my change to the url field will not affect anybody else.
Comment 55•24 years ago
|
||
Per brendan's request, the sr and r reviews need to be done by different folks. Thanks in advance, Jim
Assignee | ||
Comment 56•24 years ago
|
||
Jim, I think you misunderstood my comment above. I never said that rpotts did the review and the superreview. In fact, he is not even on the superreview list. What I said was that he did the normal review and that he did the approval as module owener. This has been submitted to mscott for a superview and I an awaiting his reply.
Comment 58•24 years ago
|
||
I second Rick's suggestion of just sticking with this one line patch for the branch and tip and then opening a new bug (non rtm of course) to track the problem with using the default load channel. I don't see much risk in resetting the url scheme after the redirect. sr=mscott
Comment 59•24 years ago
|
||
What's the new bug number (the one about updating the loadgroup to track the redirect)? Thanks. /be
Assignee | ||
Comment 60•24 years ago
|
||
The bug to track the redirect problem is bug 55867. This bug now has review, super review, and module owner approval. So I'm removing the [needs info] to get this onto the pdt radar.
Whiteboard: [rtm need info] → [rtm+]
Comment 61•24 years ago
|
||
Who has approved the change for HTTP? the proposed change could have possible effects on interpretation of mURI in nsHTTPChannel. Moving this back to rtm need info till reviewed.
Whiteboard: [rtm+] → [rtm need info]
Assignee | ||
Comment 62•24 years ago
|
||
Gagan, This change was reviewed by rpotts. And he approved it as module owner. It was then super-reviewed by mscott. All this is contained in the comments above.
Comment 63•24 years ago
|
||
Rick, Could you comment on Gagan's fears listed above? We'd like to get closure, and get this bug landed RSN. Thanks, Jim
Comment 64•24 years ago
|
||
hey jim, Gagan and I talked about this bug last week... We came up with a cleaner fix which should be no more scary than the one proposed by steve :-) The fix is to update the LoadGroup's defaultLoadChannel whenever a redirect occurs on the current defaultLoadChannel... So, the login goes something like this: 1. A rediect occurs... 2. Get the defaultLoadChannel of the channel's loadgroup. 3. Create the new channel for the redirect... 3. if the channel being redirected is the same as the defaultLoadChannel in the loadgroup then set the defaultLoadChannel to the new channel. This same login should be applied to client auth which is the other situation where the defaultLoadChannel in the loadgroup can become out of sync with reality... I believ that gagan is going to propose this fix... -- rick
Assignee | ||
Comment 65•24 years ago
|
||
OK, I've taken this as far as I can. Reassigning to gagan.
Assignee: morse → gagan
Status: ASSIGNED → NEW
Component: Cookies → Networking
Assignee | ||
Comment 67•24 years ago
|
||
Received the outlines of a patch from gagan, so I'm taking this back and will champion it. I'll attach the patch now.
Assignee: gagan → morse
Assignee | ||
Comment 68•24 years ago
|
||
Assignee | ||
Comment 69•24 years ago
|
||
Gagan, please give your aproval (or dis-approval) as module owner. Thanks. Dan Veditz has already reviewed it and will be putting his r=dveditz in the bug report shortly.
Comment 70•24 years ago
|
||
morse: the diffs look ok to me. does this fix the bug? if so, r=gagan. you should get sr from rpotts on this. thanks!
Assignee | ||
Comment 71•24 years ago
|
||
Can't get an sr from rpotts because he's not on the super-reviewer list. The correct person is mscott, who did the super review before.
Status: NEW → ASSIGNED
Comment 72•24 years ago
|
||
r=dveditz as well, and I saw the before-and-after proof that this patch fixes this problem.
Assignee | ||
Comment 74•24 years ago
|
||
All reviews and approvals are in place. Off to pdt.
Whiteboard: [rtm need info] → [rtm+]
Comment 75•24 years ago
|
||
rtm++. I wonder whether a comment on the patch is appropriate, unless you think it'll be obvious to future readers why that's necessary.
Whiteboard: [rtm+] → [rtm++]
Assignee | ||
Comment 76•24 years ago
|
||
Fix checked in on branch and trunk.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Comment 77•24 years ago
|
||
verified on branch winNT4 2000102008 needs verified on trunk
Keywords: vtrunk
Comment 78•24 years ago
|
||
verified on trunk oct. 24 Linux RH7 oct. 24 WinNT 4.0 oct. 23 Mac OS9 Able to log into mail.yahoo.com with those respective builds. Removing vtrunk keyword and marking bug as verified.
Status: RESOLVED → VERIFIED
Comment 80•24 years ago
|
||
RELNOTE Patrol: -> cookies. Might want to remove relnote3 since this is fixed and not in current relnotes.
Component: Networking → chatzilla
Updated•20 years ago
|
Product: Core → Other Applications
You need to log in
before you can comment on or make changes to this bug.
Description
•