dashboard.twitch.tv - see bug description

[denschub]

URL: https://dashboard.twitch.tv/extensions/search?q=crowd

Browser / Version: Firefox 111.0 Operating System: Mac OS X 10.15 Tested Another Browser: Yes Chrome

Problem type: Something else Description: Auth flow iFrame gets blocked by X-Frame-Options Steps to Reproduce: The STR are:

1. Go to the Twitch Creator Dashboard
2. Add a third-party Extension to your channel, like Crowd Control, for example
3. Try to authorize it, and observe the blocked iFrame
   View the screenshot

   

Browser Configuration

• gfx.webrender.all: false
• gfx.webrender.blob-images: true
• gfx.webrender.enabled: false
• image.mem.shared: true
• buildID: 20230122093201
• channel: nightly
• hasTouchScreen: false
• mixed active content blocked: false
• mixed passive content blocked: false
• tracking content blocked: false

View console log messages

From webcompat.com with ❤️

[denschub]

I became aware of this while watching a streamer mentioning that this is broken in Firefox. It's also been reported at https://github.com/twitchdev/issues/issues/523

This appears to be working in Chrome, so let's check what the difference in implementations is, here. If anything, we should reach out to Twitch folks if this is something that needs to be fixed on their end.

[denschub]

So yeah, this is a bit weird. Trying to add Crowd Control to my channel, I initially see the the OAuth access propt as you'd expect. That's an <iframe> at https://id.twitch.tv/oauth2/authorize, and the response there does not have any X-Frame-Options header set.

However, on clicking "authorize", the dialog is doing a POST to https://id.twitch.tv/oauth2/authorize, and that in turn loads a document that attempts to redirect the user using

window.location = "https:\/\/www.twitch.tv\/extensions\/oauth-redirect#...";

this is where it fails, as that response has X-Frame-Options: SAMEORIGIN set. www.twitch.tv and dashboard.twitch.tv are different origins, so Firefox refuses to load that. Firefox wants to be helpful and suggests opening the site in a new tab, but that doesn't work either, as the oauth-redirect page wants to postMessage things to window.parent, so that's not going to work.

I am, however, slightly confused by this. To my knowledge (and according to WPT), both Firefox and Chrome are supposed to block cross-origin framing. So, in theory, this should fail in Chrome as well - assuming we get the same response. It's possible that Chrome does something unexpected here, but it's also possible that Twitch is sending something different to Chrome.

Unfortunately, I ... can't verify what Chrome gets, at the moment. If I try to log into Twitch using a Chrome release 109, I get this lovely message from Twitch:

Sooo, uh. Before I try spoofing my Chrome UA to an older version, I'll just end my day and come back to this later this week, hoping that whatever is preventing me from signing in in Chrome magically resolves itself.

[denschub]

Ah I can finally log in from Chrome! Cool!

As already assumed, adding the same extension works fine in Chrome. I was able to record the entire flow, and looking at it, both Firefox and Chrome receive the same general flow. However, when Chrome does the GET https://www.twitch.tv/extensions/oauth-redirect, there is no X-Frame-Options in the response, while in Firefox, there is. If I hack the header into Chrome's response, Chrome also refuses to load that frame, just like you'd expect.

One correction from my previous comment is that the POST to https://id.twitch.tv/oauth2/authorize is not actually forwarding the user to oauth-redirect via JS. Instead, they're using a <meta http-equiv="refresh" content="0;URL='...'" /> - the JS is only there as a fallback, and requires manual user interaction.

I'm saying that because the request to oauth-redirect does not have a Referer set. Firefox probably should set one, but we don't, see https://bugzilla.mozilla.org/show_bug.cgi?id=1479017. Chrome does set Referer: https://id.twitch.tv/. It's possible that twitch is adding the X-Frame-Options header if they think the request is from a third-party origin, and if that's the case, I might not be able to convince them to actually change their behavior here, as there is some reasoning behind it.

And unfortunately, this seems to be exactly the case here. If I hack a Referer: https://id.twitch.tv/ into Firefox' request to the oauth-redirect endpoint, but leave all other requests and fields untouched, I don't see a X-Frame-Options response header, and everything works fine. So this is, unfortunately, caused by https://bugzilla.mozilla.org/show_bug.cgi?id=1479017

[maxcalvin]

@denschub really appreciate the breakdown in your post, with all the detail about why this is happening.

As an extension author who gets the occasional emails from streamers who are unable to activate the extension, we could almost guarantee it was Firefox and reply with 'you need to use chrome to add it to your page'. Never dug too far into the reason though.

Hopefully when this gets out we will see an uptick in Firefox streamers installing again 😁

Cheers!