www.twitch.tv - see bug description

[webcompat-bot]

URL: https://www.twitch.tv/settings/profile

Browser / Version: Firefox 58.0.2 Operating System: Windows 10 Tested Another Browser: Yes

Problem type: Something else Description: I cannot save changes on profile page Steps to Reproduce: Just access the page.

From webcompat.com with ❤️

[adamopenweb]

I can reproduce this issue in FF 58 & 60 for OSX. Works as expected in Chrome.

Console error on load:

TypeError: document.body is null[Learn More] player.js:28:618841

Same thing appears in Chrome though:

player.js:28 Uncaught (in promise) TypeError: Cannot read property 'appendChild' of null
    at player.js:28
    at new Promise (<anonymous>)
    at player.js:28
    at Object.<anonymous> (player.js:28)
    at t (player.js:1)
    at player.js:1
    at player.js:1
    at player.js:1
    at player.js:1

[miketaylr]

We're sending a PUT request to https://api.twitch.tv/kraken/users/[username], which returns 401.

Spoofing as Chrome has no effect... let me see if mozregression turns anything up.

[miketaylr]

This fails as far back as 50, so I suspect this is something that is broken on the Twitch backend. (Unless it's never worked?)

[miketaylr]

In Chrome you do a PUT to https://api.twitch.tv/kraken/users/[username], which is 200. It then does a POST to https://www.twitch.tv/settings, which returns a 302 to https://www.twitch.tv/settings/profile. It then does a PUT to https://api.twitch.tv/api/users/[username], but gets a 406 Not Acceptable.

That request chain seems a little broken, but it seems like it doesn't matter since it go a PUT 200 to the kraker/users/foo endpoint.

[karlcow]

We're sending a PUT request to https://api.twitch.tv/kraken/users/[username], which returns 401.

@miketaylr what are the cookies or Auth stories in the HTTP headers for both chrome and Firefox?

[denschub]

So, comparing the two requests from Chrome and Firefox here.

Firefox:

curl -v 'https://api.twitch.tv/kraken/users/denschub' \
  --compressed \
  --data 'displayname=denschub&email=SNIP&description=&on_site=1' \
  -H 'Accept-Language: en-us' \
  -H 'Accept: application/vnd.twitchtv.v4+json' \
  -H 'Cache-Control: no-cache' \
  -H 'Client-ID: SNIP' \
  -H 'Connection: keep-alive' \
  -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' \
  -H 'Cookie: SNIP' \
  -H 'DNT: 1' \
  -H 'Host: api.twitch.tv' \
  -H 'Pragma: no-cache' \
  -H 'Referer: https://api.twitch.tv/crossdomain/receiver.html?v=2' \
  -H 'Twitch-Api-Token: SNIP' \
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0' \
  -H 'X-CSRF-Token: SNIP' \
  -H 'X-Requested-With: XMLHttpRequest' \
  -X PUT

Chrome:

curl 'https://api.twitch.tv/kraken/users/denschub'
  --compressed
  --data 'displayname=denschub&email=SNIP&description=&on_site=1'
  -H 'accept-encoding: gzip, deflate, br'
  -H 'accept-language: en-us'
  -H 'accept: application/vnd.twitchtv.v4+json'
  -H 'authority: api.twitch.tv'
  -H 'cache-control: no-cache'
  -H 'client-id: SNIP'
  -H 'content-type: application/x-www-form-urlencoded; charset=UTF-8'
  -H 'cookie: SNIP'
  -H 'origin: https://api.twitch.tv'
  -H 'pragma: no-cache'
  -H 'referer: https://api.twitch.tv/crossdomain/receiver.html?v=2'
  -H 'twitch-api-token: SNIP'
  -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36'
  -H 'x-csrf-token: SNIP'
  -H 'x-requested-with: XMLHttpRequest'
  -X PUT

Both requests are basically the same (the authority is equivalent to the host header for http2), the only difference is the missing origin header in Firefox. And sure enough, if I manually add the header in Firefox, the request returns 200.

I am not sure about the actual rules on when we should send an origin header and when not, but given this is XHR related, I have the strong suspicion that @wisniewskit knows more.

[wisniewskit]

This seems to be related to bug 1424076, as when I set the related about:config preference (network.http.sendOriginHeader=1) the request seems to work. That means this is related to Origin header CSRF mitigation, and Twitch can likely work around it on the server-side by allowing Firefox through until that bug is fixed and hits a stable release.

[denschub]

You are perfectly right, thank you!

So, instead of rejecting the request, twitch should probably fall back to the referer header when there is no origin header, which would fix the profile saving for Firefox and Edge. With that, moving to contactready.

[adamopenweb]

We had reached out previously for this, I added the additional information to the thread.

Thanks for the great work @denschub & @wisniewskit!

[adamopenweb]

Looks like this is fixed!

Tested in Firefox 61 for MacOS.