Twitch stopped to recgonise the browser independent of configuration

tostr

I have the same problem. Changing user agent does not help. Compatibility mode does not help either.

This is the line I get in console when clicking login:
[Error] Failed to load resource: the server responded with a status of 400 (Bad Request) (integrity, line 0) https://passport.twitch.tv/integrity

Twitch does list Safari as a supported browser.

I could not find a way to contact twitch, and I do not have twitter to do so. Maybe this thread could be brought to the attention of a technical problem? Because video streaming works fine, just not login.

EricShimizuKarbstein

Vlad I was not able to contact Twitch

Charger4038

Same for me.

From https://help.twitch.tv/s/article/supported-browsers?language=en_US

If you are experiencing an issue on a non-supported browser, please contact the appropriate browser’s support team for additional assistance, or please try again on one of our supported browsers.

Capricorn

I submitted a support ticket to Twitch to let them know about this issue, and referenced this post. Will update with any response.

Cypress

I didn't see this thread before, and I also contacted Twitch.

As others have stated, everything on Twitch works as expected, except the integrity validation with Passport.

Here are the differences between the requests made by Orion and Safari to Twitch's Passport (https://passport.twitch.tv/integrity) – that are ultimately getting an HTTP/1.1 400 Bad Request:

User-agent from Safari: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.3 Safari/605.1.15
User-agent from Orion: user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15

(I correlated the difference in the Safari version from 16.3 to 16.1 since they stated they only support the latest version of Safari on their website. However, not sure if a minor version difference like this would cause any issues...)

Orion also adds these headers in the request:

sec-fetch-dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site

While other browsers don't. Not sure if this is related, but I also found some people online having problems with sec-fetch and Passport authentication.

Anyway, I tried to overwrite the headers to see if it would fix the issue, but I couldn't. If someone knows how to do that and wants to try it quickly, it may help to discover the issue! 🙂

I definitely would continue to use Orion since I love it, but I'll appreciate being able to use it to access Twitch since it is a site I use so much, and it is annoying needing two browsers and one just for one website :/

Capricorn

Twitch support was responsive but not helpful - they just suggested using a supported browser, and making a request at https://twitch.uservoice.com. I asked them to please pass the bug report to the development team, but they gave no indication of doing so.

Capricorn

I tried using the Chrome Requestly extension (http://requestly.io) in Orion to remove the three Sec-Fetch headers, and from the dev tools I can see it removed the headers properly, but I got the same error from the Twitch login page.

Vlad

Can anyone confirm in the new RC released today ? (from #rc-builds om discord)

alexkornitzer

So just tried this with the latest RC and its still failing on the integrity check even with compatability mode active.

But I was having a poke at this on the weekend and I am pretty sure this is not due to a header mismatch but actually due to Kasada Anit-Bot. I stripped off the first level of obfuscation so that the javascript was more readable and can see that this library will inject the kpsdk headers:

x-kpsdk-cd: {"workTime":1679309802217,"id":"c4425fd69e35668169c976369a631c0b","answers":[7,2],"duration":1,"d":274,"st":1679309796816,"rst":1679309796964} x-kpsdk-ct: 0Puw0EeZkC9yS9DOlHlCrb1DNi2WgLzYavzZk6ZYsNZXaqZmteeK7fDaMpCXRws7JthROON6Te3JHdTzHWsMpT4q300AFKJOQBxgZTUR2Ka5d6YKvK0gsob72a26yO2zGqD5Cw89FiE7BoJVAhCw0yimP

I did not have time to dig further to fully confirm as it seems like the timings here are really tight so I need to script some stuff up in MITM to be totally sure that Kasada is the issue. Or it could be that this is totally incorrect and something else is the issue.

alexkornitzer

Okay so have made a bit more progress on this, looks like the culprit here is the x-kpsdk-ct aka the client token. The current work around I have found is that if you take a valid client token from another cookie store i.e. safari and insert that into the Orion cookie store, the browser is then deemed valid.

Looks like the next step is going to be sifting through the obfuscated code to see how the client token is created, hopefully there is something obvious that will elude as to why Orion is failing the checks.

Vlad

alexkornitzer Great detective work!

Numline1

@alexkornitzer thank you for your dedication on this. My 5 cents:

I've been able to log in several weeks ago without any issues using an RC version. It obviously became problematic once I got logged out. However, I've noticed there was an issue with their GraphQL API even before I got logged out. Twitch has a functionality which allows you to sort of "announce" a resubscription to a streamer in the chat. It shows a popup allowing you to share a custom message. This worked, however submitting this form yielded a checksum error on the GraphQL API. This might be related to their new anti-bot protection, or maybe not, who knows.

jtsom

I just ran into this too. (Switched from another browser). Trying to log into Twitch and am seeing this error. Is there any movement on fixing this? This makes Orion useless to me.

FWIW. Safari Technology Preview also has the same problem, normal Safari logs in just fine.

Vlad

jtsom That seems to indicate the probem is with WebKit.

Someone should post an issue on webkit.org

https://webkit.org/reporting-bugs/

and confirm here with the ticket link. They are usually pretty fast to fix these.

alexkornitzer

Are we sure its actually a bug with the engine and not a breakage by design that is due to it not being a supported browser. The scripts employed by the site will intentionally create fingerprints to block unknown browsers...

I haven't had time to reverse the fingerprint fp endpoint yet.

jtsom

I just opened a ticket:

https://bugs.webkit.org/show_bug.cgi?id=254368

alexkornitzer

Ah interesting, so it is a bug, that was clearly breaking the anti-bot but nothing intentional. Looks like the fix has already been merged into WebKit: https://github.com/WebKit/WebKit/pull/10760

jtsom

FWIW, Safari Technical Preview V166 has fixed the issue.