Origin header should not be set on OpenSearch POST
Categories
(Firefox :: Search, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox74 | --- | wontfix |
firefox75 | --- | verified |
People
(Reporter: alex_y_xu, Assigned: daleharvey)
References
(Regression, )
Details
(Keywords: regression)
Attachments
(1 file, 1 obsolete file)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
- navigate to https://duckduckgo.com/lite/
- add as a search engine
- set as default search engine
- select text, right-click, "Search DuckDuckGo Lite"
Actual results:
page displays "forbidden"
Expected results:
search results displayed
this has been reported by other users in various forums, usually resolved by switching to non-Lite. I believe this is a bug though: opensearch engines should not be sent the domain of my search origin.
Comment 2•4 years ago
|
||
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0
20200207195153
You can enter about:config
into the address bar and set network.http.sendOriginHeader to 0
That seems to make the search results load. I'm not entirely sure what actually triggers the 403 forbidden response, since it worked fine at first in a brand new profile.
I reproduced it in a new profile with Firefox 73.0 on Linux.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
note that this is also an issue if you highlight the text and drag it to a new tab
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Pushed by dharvey@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c9d304142ff5 Dont send Origin header with context menu searches. r=ckerschb,Standard8
Comment 7•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Comment 8•4 years ago
|
||
Hello,
I’ve tried to reproduce this issue in order to verify it, with different Firefox versions (73.0, Nightly from 2020-02-04, latest nightly 2020-03-20 and beta 75.0b6) on different Oses : Windows 10x64, mac0S 10.15 and Ubuntu 18.04x64. Unfortunately I couldn’t reproduce it by following the str from comment 0, the searched result was displayed properly.
Alex, could you please verify if this is fixed on latest beta? (https://archive.mozilla.org/pub/firefox/candidates/75.0b6-candidates/)
Thanks.
still broken with https://archive.mozilla.org/pub/firefox/releases/74.0/linux-x86_64/en-US/firefox-74.0.tar.bz2 and new profile
working with https://archive.mozilla.org/pub/firefox/candidates/75.0b6-candidates/build1/linux-x86_64/en-US/firefox-75.0b6.tar.bz2 and new default-beta profile
thanks
Updated•4 years ago
|
Comment 11•4 years ago
|
||
Considering the privacy issue, and the straightforward fix, should we consider uplifting (some form of) this to 68 esr?
Comment 12•4 years ago
|
||
I think that would be reasonable. Dale, do you want to see if this can be uplifted to 68 cleanly? I suspect it should be possible.
Assignee | ||
Comment 13•4 years ago
|
||
Assignee | ||
Comment 14•4 years ago
|
||
[Tracking Requested - why for this release]:
As Gijs mentions, it improves privacy, fixes search engine breakage and is relatively simple
Comment 15•4 years ago
|
||
After looking at the patch on esr68, I realised that the test passed without the patch. Dale mentioned about bug 1424076, and that landed in 70.
I checked with mozregression and got:
10:31.42 INFO: Last good revision: 62286ede9f12840eb941fe849643448348704b51
10:31.42 INFO: First bad revision: c6299be2356cc2bb10f3e1e7e6f04ed2004585d3
10:31.42 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=62286ede9f12840eb941fe849643448348704b51&tochange=c6299be2356cc2bb10f3e1e7e6f04ed2004585d3
Which points to bug 1424076.
Hence, 68 isn't affected.
Updated•4 years ago
|
Updated•4 years ago
|
Description
•