Open
Bug 1246096
Opened 8 years ago
Updated 2 years ago
In case of blocking cookies from website in the exceptions, should not be added "http://" automatically
Categories
(Core :: Networking: Cookies, defect, P3)
Core
Networking: Cookies
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox44 | --- | affected |
firefox45 | --- | affected |
firefox46 | --- | affected |
firefox47 | --- | affected |
firefox-esr38 | --- | unaffected |
People
(Reporter: magicp.jp, Unassigned)
References
Details
(Whiteboard: [necko-backlog])
Attachments
(1 file)
248.45 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160204030229 Steps to reproduce: 1. Start Firefox 42.0 and later version 2. Open "about:preferences#privacy" 3. Switch to "Use custom settings for history" 4. Click "Exceptions..." button 5. Enter "google.com" 6. Click "Block" button Actual results: The website address entered is added "http://" automatically. Therefore this setting cannot block the following cookies... google.com accounts.google.com doc.google.com etc... Expected results: In case of blocking cookies from website in the exceptions, should not be added "http://" automatically. The blocking should block cookies widely for secure and privacy. (In another case of to allow cookies, should narrow)
Has STR: --- → yes
status-firefox44:
--- → affected
status-firefox45:
--- → affected
status-firefox46:
--- → affected
status-firefox47:
--- → affected
status-firefox-esr38:
--- → unaffected
Component: Untriaged → Networking: Cookies
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Comment 1•8 years ago
|
||
According to bug 1210379 comment 8 this blocking should continue to work with the http:// prefix. Does this avoid the problem?
(In reply to Josh Matthews [:jdm] from comment #1) > According to bug 1210379 comment 8 this blocking should continue to work > with the http:// prefix. Does this avoid the problem? I cannot understand http prefix needs for cookie blocking because cookies' domain does not have http prefix. How about pros cons?
Comment 3•8 years ago
|
||
Does it work, however?
(In reply to Josh Matthews [:jdm] from comment #3) > Does it work, however? Unfortunately I cannot make out what you means.
Comment 5•8 years ago
|
||
Do cookies get blocked as expected if the http:// prefix is used?
(In reply to Josh Matthews [:jdm] from comment #5) > Do cookies get blocked as expected if the http:// prefix is used? Please find attached test case.
Comment 7•8 years ago
|
||
Is this something you could look into? This seems like unintentional fallout from the permission manager changes.
Flags: needinfo?(michael)
(In reply to Josh Matthews [:jdm] from comment #7) > Is this something you could look into? This seems like unintentional fallout > from the permission manager changes. bug 1210379 comment 1
Comment 9•8 years ago
|
||
(In reply to Josh Matthews [:jdm] from comment #7) > Is this something you could look into? This seems like unintentional fallout > from the permission manager changes. The problem in this case appears to be that the permissions in the new case are set with the `www.` prefix. If that was done in the old model, the same effect will occur. Try adding permissions for `https://google.com` and `http://google.com` instead. www. acting different than the base domain is intended, and occurred before the update.
Flags: needinfo?(michael)
Reporter | ||
Comment 10•8 years ago
|
||
(In reply to Michael Layzell [:mystor] from comment #9) > The problem in this case appears to be that the permissions in the new case > are set with the `www.` prefix. If that was done in the old model, the same > effect will occur. Try adding permissions for `https://google.com` and > `http://google.com` instead. I tried it. Certainly, it seems working as "http(s)://*.google.com". It's a tentative solution?
Comment 11•8 years ago
|
||
(In reply to magicp from comment #10) > (In reply to Michael Layzell [:mystor] from comment #9) > > The problem in this case appears to be that the permissions in the new case > > are set with the `www.` prefix. If that was done in the old model, the same > > effect will occur. Try adding permissions for `https://google.com` and > > `http://google.com` instead. > > I tried it. Certainly, it seems working as "http(s)://*.google.com". It's a > tentative solution? Try just http(s)://google.com - I don't think we intend to allow http(s)://www.google.com to apply to http(s)://maps.google.com etc., as they are different subdomains, and thus can have separate permissions.
Reporter | ||
Comment 12•8 years ago
|
||
(In reply to Michael Layzell [:mystor] from comment #11) http(s) is not my request. just writing for short word. sorry for confusing.
Updated•8 years ago
|
Whiteboard: [necko-backlog]
Comment 13•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Comment 14•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•