Open
Bug 1454022
Opened 7 years ago
Updated 2 years ago
referrer dropped in a case where Chrome and Safari keep it
Categories
(Core :: DOM: Navigation, defect, P3)
Core
DOM: Navigation
Tracking
()
NEW
People
(Reporter: dietrich, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: compat, DevAdvocacy)
Tested in a new profile on Firefox release, nightly and 52 ESR, the problem occurs in all of them.
The scenario is a website doing the Twitter oauth flow. It doesn't technically require the referrer in order to function, but the author wrote it that way, and it seems like it should work ok.
STR:
1. open https://mirage-velvet.glitch.me/
2. click "log in with twitter" and follow the Twitter oauth flow
Expected: Can log in using Firefox.
Actual: Firefox doesn't work - you end up on the originating site after authenticating with Twitter, but this is not recognized on the originating site. Chrome and Safari work fine.
I'm pretty sure I've narrowed it down to this:
After the oauth verification is complete, Twitter redirects back to the originating website.
When Firefox makes that request to the originating website, we do not set the referrer header. Chrome and Safari do set the referrer header.
I'm the author of the app in question in Dietrich's post, and I wanted to add that this same behavior occurred even when I changed the value of network.http.sendRefererHeader to options that enable referer.
Reporter | ||
Updated•7 years ago
|
Keywords: compat,
DevAdvocacy
Reporter | ||
Comment 2•7 years ago
|
||
Some more info: https://twitter.com/_gw/status/986542965010190336
The referrer is not sent in the redirect to Twitter and Github, but *is* sent in the case of Azure, Google and Foursquare.
Again, Chrome works as expected in all of these.
Here's the same approach as the Twitter example above, but with Google: https://glitch.com/edit/#!/google-passport-oauth
Reporter | ||
Comment 3•7 years ago
|
||
Jason, any ideas on why we might behave differently here?
Flags: needinfo?(jduell.mcbugs)
Comment 4•7 years ago
|
||
The return from twitter is doing a meta refresh:
<meta http-equiv="refresh" content="0;url=https://tricky-rhythm.glitch.me/login/twitter/return?oauth_token=2GKNsQAAAAAA5sdAAAABYuYXh9E&oauth_verifier=1GpdiXGrOEQuvN7Hrq8fSl6fcsnNltZY">
I'm sorry to say this is a 14 year old bug on us not sending referer header on meta refresh. See bug 266554.
Comment 5•7 years ago
|
||
(In reply to Ben Kelly [:bkelly] from comment #4)
> The return from twitter is doing a meta refresh:
>
> <meta http-equiv="refresh"
> content="0;url=https://tricky-rhythm.glitch.me/login/twitter/
> return?oauth_token=2GKNsQAAAAAA5sdAAAABYuYXh9E&
> oauth_verifier=1GpdiXGrOEQuvN7Hrq8fSl6fcsnNltZY">
>
> I'm sorry to say this is a 14 year old bug on us not sending referer header
> on meta refresh. See bug 266554.
Is this just a straight "DUPLICATE" of that bug?
Reporter | ||
Comment 6•7 years ago
|
||
Thanks Ben for finding the meta refresh issue, finding the bug filed by the ancient ones, and for driving towards a solution in that bug!
Re duplicate: I'll leave it to Ben to decide whether it's more useful to block on it or dupe it. My tendency is to keep specific use-cases open and block on the source bug, as it keeps those issues real and fresh. Duping tends to wrap up all the individual use-cases and hide them away, never to be seen again, often dropping them from the conversation in the source bug. But I'm not a peer in this area of code, so it's up to them.
Comment 7•7 years ago
|
||
Note, this glitch app also fails in edge because of the issue described in bug 266554 comment 64.
Updated•7 years ago
|
Priority: -- → 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
•