plugins.twitch: add --twitch-force-client-integrity, remove CI token decoding+parsing logic #6113
Conversation
A different client-integrity token format is returned now which includes encrypted data, so we can't decode and parse the data anymore in order to check whether `is_bad_bot is False`. If `is_bad_bot is True`, then requesting the streaming access token might fail, which is the same result.
I don't think this is the case. There are still some GQL requests that will fail an integrity check on default headless (with the HeadlessChrome user agent), for example, requesting further than page 1 on a stream directory listing. In my testing, these requests pass the integrity test if the HeadlessChrome user-agent is overridden with the one from the base browser. That being said, I've just tested one of these endpoints with a token generated by headless Chromium using this patch, and it fails the integrity test. Notice If you look at the logic in Selenium: |
|
Sorry, to be more clear, this patch works correctly and generates good tokens when used in non-headless mode, forcing headless is what causes the above issue, so it was in response to your question about that. |
Yes, all good, I'm fully aware...
Reading the UA and then modifying it requires a secondary web browser launch and CDP initialization, which I tried to avoid by re-using the UA string from Streamlink's useragents module. This is obviously limited to only one platform, which is the Windows-desktop one (it was chosen because it's the one that had and still has the highest market share, so Streamlink's HTTP requests don't stand out in server logs). Reading the UA from a secondary launch could of course be cached, but it'd still require a more sophisticated initialization logic and a cache expiration, so not much is gained from this solution. There are two other solutions though for overriding the UA header in the CDP session and that's:
But let's not discuss this here. It's off topic. This PR is about the added plugin argument and CI token decoder removal, which is working fine. Please open another issue for potential headless changes of the Twitch plugin. Thanks. |
Resolves #6109
--twitch-force-client-integrityplugin argument (I didn't want to add another plugin arg when the CI token stuff was implemented, but since people are actively patching the plugin, let's just add the arg to make their lives a bit easier)I also checked removing the
headless=Falseoverride, and requesting access tokens worked just fine. This however might be because they simply don't care about theis_bad_botflag right now. So what should we do now? Remove the value override and let the user decide again via--webbrowser-headless(defaults toTrue)? Should Twitch make any changes though, then people will actively have to set--webbrowser-headless=false, which was the point of the override.@Hakkin, any opinions on that?