-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
plugins.twitch: add support for passing auth credentials #4080
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
bastimeyer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR.
When Twitch disabled 3rd party Client-IDs on their old private /api API endpoints used for retrieving the access token, we had to remove the --twitch-oauth-token parameter, because it was not possible anymore to authenticate with OAuth tokens generated with Streamlink's Client-ID. Even though we could've changed it to let users use their OAuth token from Twitch's website by extracing it from their web browsers, we removed the plugin parameter, because we feared that it would cause too many issues for regular users or lots of unnecessary questions on the issue tracker, and we didn't want to deal with that. Authenticating via --http-header has always been the option since then for advanced users and those who knew what they were doing. This has not changed with the switch to Twitch's GQL API for retrieving the access token. But yes, this would also update the headers of HLS playlist+segment requests, which is not ideal.
I don't want to stand in the way of a re-implementation of the auth parameter though, but I think that there needs to be a bit more clarification in the docs about what this does and what needs to be done by the user.
I also don't think that the auth parameter should be called auth-token when we already had oauth-token in the past, and adding a second parameter for the device ID (which is required as well for properly authenticating) is IMO unnecessary. I understand though that it might be easier from a user perspective to have two separate parameters for two separate values, but whenever a new parameter gets added (plugin specific or not), we always also have to think about a potential deprecation and removal if stuff breaks or needs to get changed. I can see this being the case here rather quickly, especially after the recent Twitch code leaks, so having a single auth parameter makes more sense to me. This needs to be discussed.
Regarding your implementation of the header property, it gets read on every single access, which should be changed. It should only be updated once during initialization of the TwitchAPI class instance.
Since we need to discuss how the plugin arguments should be implemented, I'm not going to comment on the wording of the help texts just yet. The arguments order however will probably need to be changed, because that's relevant for the docs and man page.
|
or just change the header instead of this PR it might also remove ads headers = {
"Client-ID": "...",
"X-Device-Id": "twitch-web-wall-mason",
"Device-ID": "twitch-web-wall-mason",
}it will change https://github.com/pixeltris/TwitchAdSolutions/blob/master/bypass/bypass-ublock-origin.js |
|
@back-to this solution is not reliable. All it takes from Twitch is to change the constant value to render workaround unusable. |
|
Recent events revealed that
X-Device-Idis used not only for statistics and being authorized directly relates to whether you should be served server-side ads or not. Let's add this function back. It's no use for regular users, but for those who automate stream recording or build tools around streamlink - should be handy.Alternatively,
http-headersoption could be used, but if I read the documentation right, it will inject header into all the requests (including hls stream), which is undesirable (this kind of auth is specific only to twitch gql api).