1278054 - selectively accept cookies fails under win7sp1 64bit

Status: RESOLVED INVALID

(Core :: Networking: Cookies, defect, P2)

Description

[scratch65535]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042

Steps to reproduce:

With a fresh install of Win7sp1 64bit, and a fresh install of FF 46.0.1 64bit ---
Select "Use custom settings for history"
Deselect "Accept cookies from sites"
Add "amazon.com" to exceptions list, save changes.
Attempt to log in to amazon.com


Actual results:

Amazon demands that cookies be enabled, and won't let me in until I select "Accept cookies from sites", though I can leave 3rd party cookies set to "Never".

When I select "Accept cookies" and go back to log in, I find that my email address has "999-9999999-9999999?UTF8" appended to it (the digits aren't 9s, but I don't want to reproduce them in case they're significant).  The word size may not be significant, but that hasn't happened under 32-bit versions of FF.


Expected results:

Amazon should have let me log in, as it does with the same settings under XPsp3

Comment 1

[Daniel Stenberg [:bagder]]

Sounds related to or a dupe of bug 1276462. Valentin, your thoughts?

Comment 2

[Valentin Gosu [:valentin] (he/him)]

That was a nightly only bug, and was quickly fixed.
I am quite sure it shouldn't affect Firefox 46. We need to investigate, especially if there is a 32/64 bit difference in behaviour.

Comment 3

[Loic]

The digits added after the email address in the login form are related to the session ID used by Amazon to identify each session open on the website (it's displayed in the URL too).

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=443582420f2c6643112ebe3869c75294478c3f0b&tochange=fb346b9b9f9878df57fef570612ef043c7d2ba4e

I'd say it regressed by bug 1165263.

Comment 4

[Loic]

Attachment: amazon.com-login-form-FF47.jpg

Comment 5

[Alice0775 White]

(In reply to Loic from comment #3)
> The digits added after the email address in the login form are related to
> the session ID used by Amazon to identify each session open on the website
> (it's displayed in the URL too).
> 
> Regression range:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=443582420f2c6643112ebe3869c75294478c3f0b&tochange=fb34
> 6b9b9f9878df57fef570612ef043c7d2ba4e
> 
> I'd say it regressed by bug 1165263.

Yes.
The cookie exception of amazon for login is "https://amazon.com". 
And I can log-in the site without problem on Firefox47.


And the extra strings for logib-id is also added on Google Chrome if disabled Cookies.
So I think this is the site BUG.

Comment 6

[Ian Nartowicz]

Since bug 1165263, separate exceptions are required for http and https domains.  So an exception for http://amazon.com will not allow you to login since the login is done by https://amazon.com.  The exception dialog still accepts plain amazon.com, but only adds an http://amazon.com exception which is insufficient in this case.  Try explicitly adding https://amazon.com and see if that helps.  Ports are also a necessary part of the exception, but it is quite rare for anything other than the implicit port 80 to be required.

Comment 7

[Daniel Stenberg [:bagder]]

> it is quite rare for anything other than the implicit port 80 to be required.

And port 443 for HTTPS:// URLs presumably. And since we're talking about the amazon.com web site here, I would assume that specifying "https://amazon.com" should suffice.

scratch65535, can you try adding the exception with https:// and see if that fixes the problem?

Comment 8

[Loic]

Yes, it works fine with "https://amazon.com" added to the exception list, Amazon doesn't display any error message about cookies blocked.

Comment 9

[Valentin Gosu [:valentin] (he/him)]

So it's pretty safe to say this is not a bug?

Comment 10

[scratch65535]

Thanks, guys, adding a separate exception works a treat.

Is the need for separate http/https exceptions documented somewhere prominent?  I've not seen it.

UI suggestion:  space-pad the front of the http: in the exceptions list so that you can sort on the site name and the http: & https: exceptions for a given site will appear together.

Comment 11

[Loic]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1210379#c8

Comment 12

[scratch65535]

If the only documentation is in the bugs db, I'd strongly urge that a prominent note be added to the exceptions page itself, bold #990000 red with a box surround (to account for individual differences in perception), stating that an explicit "https:" exception must be added for sites that use https:, or if EFF's "HTTPS Everywhere" utility is installed.