Shields: Twitch badges failing

[chris48s]

Are you experiencing an issue with...

• [x] [shields.io](https://shields.io/#/)

:beetle: Description

Looks like our twitch badges are failing in production and in the service tests. I grabbed the TWITCH_CLIENT_ID and TWITCH_CLIENT_SECRET from heroku and ran the tests locally. The error is:

{"error":"Unauthorized","status":401,"message":"Client ID and OAuth token do not match"}

It looks like CircleCI is using different tokens than production, but I guess the failure is the same.

:link: Link to the badge

examples:
- http://img.shields.io/twitch/status/andyonthewings
- http://img.shields.io/twitch/status/noopkat

:bulb: Possible Solution

Clearly we need new tokens. @PyvesB I think the tokens are linked to your account, but also if these need rotating occasionally, maybe we need a better solution to this?

[PyvesB]

Thanks for reporting this.

Looking back at the Circle CI history, these tests have been failing for about a month, since May 12th.

I've just logged into the Twitch developer console, there's nothing that suggests that the credentials have expired. In particular, the ones on the CI are recent and were generated in March 2020 as part of #4061.

Generating new credentials does not help and I can't see any code changes on our side that could have obviously broken these badges.

Digging through some of the twitch announcements, I noticed this article. They made changes to their authentication mechanism, with a permanent switch on May 11th, which corresponds timing-wise. I haven't fully read the details, but I'm under the impression that we have to switch from query string auth to an Authorization: Bearer header. I'll do some more digging and experimentation later in the week. @andyli you originally contributed these badges, feel free to help out as well. 😉

Note that I've double checked my emails, including the spam folder, I was not warned about such a change. No notification or anything similar on my Twitch account either. An obscure post on their own forums and scheduling 3 small windows where they failed non complying requests seems like an extremely poor way of warning developers about breaking changes to their API.

[PyvesB]

I haven't fully read the details, but I'm under the impression that we have to switch from query string auth to an Authorization: Bearer header.

Ignore this part of the analysis, it's wrong: I've read through our Twitch code again and reminded myself how it works, we are doing the right thing at first glance. However, I think there's a bug in the details of the code, we're not actually setting the Client-ID as required. Will investigate further and try to come up with a fix.