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)

Product:
Other Applications
Component:
ChatZilla
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: gregk72, Assigned: morse)

References

(
URL
)

Details

(Whiteboard: [rtm++])

Attachments

(3 files)

patch to not check for originating server when sending cookies
(deleted), patch
Details | Diff | Splinter Review
patch to update originating-server when redirection occurs
(deleted), patch
Details | Diff | Splinter Review
New patch to fix the problem
(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.
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
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! :)

See bug 28545 which sounds like the same sort of problem as reported here.
*** Bug 28545 has been marked as a duplicate of this bug. ***
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 → ---
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
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.
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
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.
*** Bug 28795 has been marked as a duplicate of this bug. ***
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.
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!

I'm reassigning this back to you Steve since Greg's tests point to cookie 
management rather than migration.
Assignee: dbragg → morse
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?

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
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.
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
Continuing in my attempts to get the invalid indicator to appear.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → INVALID
OK, this time it worked.  Don't know what I did wrong previously.
ok
Status: RESOLVED → VERIFIED
*** Bug 33431 has been marked as a duplicate of this bug. ***
*** Bug 35581 has been marked as a duplicate of this bug. ***
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."
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


*** Bug 44865 has been marked as a duplicate of this bug. ***
*** Bug 45049 has been marked as a duplicate of this bug. ***
*** Bug 49445 has been marked as a duplicate of this bug. ***
*** Bug 51495 has been marked as a duplicate of this bug. ***
*** Bug 54563 has been marked as a duplicate of this bug. ***
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?
Status: VERIFIED → REOPENED
Keywords: relnote3, relnoteRTM, rtm
Resolution: INVALID → ---
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.

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.

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.

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
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.
It's definitely a cookie problem.  Reassigning back to myself.
Assignee: dbragg → morse
Component: Profile Migration → Cookies
QA Contact: gbush → tever
Status: NEW → ASSIGNED
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]
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.


  

  



    
    

    
  
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.


  

  



    
    

    
  
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.

  

  



    
    

    
  
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.

  

  



    
    

    
  
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;


  

  



    
    

    
  
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.

  

  



    
    

    
  
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.

  

  



    
    

    
  
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


  

  



    
    

    
  


  

  

  



    
    

    
  
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.


  

  



    
    

    
  
Per brendan's request, the sr and r reviews need to be done by different folks.
Thanks in advance,
Jim


  

  



    
    

    
  
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.

  

  



    
    

    
  
r=rpotts

  

  



    
    

    
  
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

  

  



    
    

    
  
What's the new bug number (the one about updating the loadgroup to track the
redirect)?  Thanks.

/be

  

  



    
    

    
  
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+]

    
    

    
  
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]

    
    

    
  
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.

  

  



    
    

    
  
Rick,
Could you comment on Gagan's fears listed above?  We'd like to get closure, and
get this bug landed RSN.
Thanks,
Jim


  

  



    
    

    
  
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

  

  



    
    

    
  
OK, I've taken this as far as I can.  Reassigning to gagan.

  

  


Assignee: morse → gagan
Status: ASSIGNED → NEW
Component: Cookies → Networking

    
    

    
  
*** Bug 55561 has been marked as a duplicate of this bug. ***

  

  



    
    

    
  
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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        New patch to fix the problem (deleted)
        — 
          — Splinter Review
      

    


  

  

  



    
    

    
  
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.

  

  



    
    

    
  
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!

  

  



    
    

    
  
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

    
    

    
  
r=dveditz as well, and I saw the before-and-after proof that this patch fixes 
this problem.

  

  



    
    

    
  
sr=mscott

  

  



    
    

    
  
All reviews and approvals are in place.  Off to pdt.

  

  


Whiteboard: [rtm need info] → [rtm+]

    
    

    
  
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++]

    
    

    
  
Fix checked in on branch and trunk.

  

  


Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
verified on branch
winNT4 2000102008

needs verified on trunk

  

  


Keywords: vtrunk

    
    

    
  
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

    
  
Keywords: vtrunk

    
    

    
  
Removing relnoteRTM keyword.


  

  


Keywords: relnoteRTM

    
    

    
  
RELNOTE Patrol:
-> cookies.
Might want to remove relnote3 since this is fixed and not in current relnotes.


  

  


Component: Networking → chatzilla
Product: Core → Other Applications

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: