I recently tried to get Hype Train Events from any Channel via User Token.
This also worked, although according to the documentation it shouldn’t be possible. As of today, this no longer works. So I tried using the app token as described in the documentation. However, here I get a 401 - Unauthorized - incorrect user authorization error.
Is this behavior correct? Because the documentation reads as if you could read the Hype Train Events from every channel using an app token.
Sounds like you found a security bug that has now been resolved.
This sounds like the same bug I found and reported late last week. Since you shouldn’t be able to read anyone’s hypetrains without prior permission.
You can use an app access token if the user has authenticated/permitted your clientID with the scope once.
So I can use my app access token to read cohhcarnage’s hypetrains as he has authorised me once with a user token with the needed scope
But I can’t use my app access token to read lirik’s hypetrains as he has not authorised me once with a user token with the needed scope
It only lets you read channels that you have permission from
As follows:
You use an app access token
twitch checks if the token is valid
twitch gets the clientID for that token
twitch checks if the requested channel has granted channel:read:hype_train scope via the user oAuth flow
Basically the same auth flow as how eventsub works.
TLDR you found a security bug, which has now been fixed.
However currently looks like App Access Tokens do not work at all. Even with prior authentication.
Why is this locked off, exactly? The information can be accessed by any viewer in chat, yet the API is restricted to the broadcaster. Why? What is the security risk here?
It may not be a security risk, it may simply be that there is no legitimate use case that Twitch want to support for 3rd parties to access that data without the user token from the broadcaster with appropriate scope.
If you have a use case that would require using an App token rather than the broadcasters token granting the appropriate scope you can create a feature request for it https://twitch.uservoice.com/forums/310213-developers
Nonsense. If Twitch didn’t want people to access that data, they wouldn’t make it available to viewers on the web site. I don’t need broadcaster authentication to go to the page in a browser and get the info.
Which means, ultimately, that I can get the information by using undocumented API calls or by scraping the web site, but I can’t use the official API unless I get the consent of the broadcaster. What exactly are you advocating here?
Theoretically, access to hype trains via the API, grants not just access to real time date, but to the historical data for hype trains (around 5 days iirc).
This means, in theory, you can use this data to help estimate the income of a streamer.
That, in my opinion, is why the API requires authorisation from the channel to access the broadcasters data.
Hype Train data belongs to the streamer and third party access to that data is governed by the permissions system.
TLDR: the data belongs to the streamer. The streamer will want to control whom can access it. And Twitch will surface only the relevant data to the front end to run the site.
It’d be pretty hard to estimate a streamer’s income based on hype train history (you only get the one most recent train, not a full history), but sure. Okay. Make it so that hype train status is only available if the hype train is active or in cooldown, or if you have broadcaster permission. That would be reasonable. But active hype trains are public information.
If the data is being surfaced for the front end, it should be surfaced for the API. Information that is available unauthenticated does NOT belong to the streamer - it belongs to everyone.
That’s the business decision made by twitch. You can certainly submit a user voice and request changes, but until you do, you have to limit yourself to the access that twitch decides to put in place.
If you are working with a streamer you can obtain permission from that streamer?
Anything else would suggest a use case that Twitch doesn’t support.
As WLG3R noted here
A lot of uservoices I have raised have been actioned, so yes something does happen with Uservoices. I keep a spreadsheet so I can refer people to various UV’s for Discord help/upvotings
UserVoice is the primary way to provide feature requests to Twitch.
So the question here really is why do you need access to hype trains for streamers you are not working with? Whats the use case? Why is it a problem to get authentication from the stremer?
When a hype train happens, the streamer is busy doing things. Having to say “oh, can you please go to this web page and click Authenticate” is a barrier that is completely unnecessary.
Also, does it even matter? The streamer doesn’t need to authenticate me to see what’s in chat. But to get the exact same information in a separate web page requires the streamer’s permission. Considering that I watch a lot of streamers, and not all of them should be required to grant me permissions, it’s a pretty serious limitation.
Without broadcaster authentication, I can connect to chat and simply monitor all cheers and sub notifications. I could easily leave a bot permanently connected, and I’d get far more of a view of the streamer’s income than a current hype train will give. This is not about protecting streamer income information.
Then you get an access token with the relevant scopes before the streamer goes live or when you start working with them
You don’t ask for a token when a train starts, you get and maintain a token before they go live.
Agreed, I was just using it as an example.
This doesn’t give you the full picture, not all subs will notify and thus won’t appear in chat. but depends what you use case is for the data you need.
Because that is a third party product with a different use case, security implications and authorisation requirements to the first party product.
So you don’t work with or provide services to any of these streamers, you just watch them? i would imagine most of them don’t want you to be collecting the data, regardless of it being public on the Twitch website.
You’ve not really descirbed a use case here, so I’m still not sure what the problem is. And can’t suggest a soltuion to that problem, which is the purpose of this forum really.
I looked for and couldn’t find your uservoice. The most recent under the Developer section is off topic and a request for an Emote Activate/Deactivate for the new emote library thats coming.
If subs aren’t notified, they don’t apply to hype trains anyway, so it’s the same thing - a proper hype train API wouldn’t reveal anything that isn’t revealed already.
How is a third-party product different from the info that’s in the first party product? You still haven’t explained that.
The use case is that I can show the same info in a better way, by making use of a full web page instead of the small amount of space at the top of chat. My display can show, for instance, the full set of emotes that could be unlocked (not just the one row of “next tier will unlock these”), and other things that wouldn’t fit into the small space in the on-platform one. Do I really need broadcaster authentication for that? As a viewer, I can get all of the information, just tediously and manually and in a FAR more privacy-invading way. A proper hype train API would mean that I don’t need to snoop everything that happens. Surely that’s better?
My UV post was quite some time ago - when this first became a problem. That’s why you can’t find it - UV is way too busy. That’s also why it seems to be pretty useless.
They have different infrastructure designed based on the intended audience, different legal terms and agreements on their usage, eifferent rate limiting/accountability, and different features based on what Twitch wish to make available to 3rd parties and what use cases they wish to support.
Just because your request wasn’t adopted doesnt mean it’s useless. The vast majority of developers have no issue getting the streamers they work with to go through an OAuth flow, and following the legal agreements. Feature Requests are assessed based partly on the demand for thst feature by devs, and if its in line with the business interests of Twitch. If no one else has the issue you do, and devs/broadcasters/Twitch actually like privacy and restricting data to those who have need and permission, then it’ll likely get less attention than a feature request thats actually needed by the 3rd party dev community.