Why is asking your users to log in not an option? If they are using a client-side app then it is reasonable to ask that user for permission to make API requests on their behalf (ie, get an OAuth token from the Implicit OAuth flow, which is design for client-side apps).
There are also free/low cost servers or serverless infrastructure available such as that offered by AWS that can handle an OAuth flow and deal with an API requests on an on-demand basis so you don’t pay anything except for when you actually make requests and even then they have free tiers on many of their services.
If you’re still not able or willing to do either of those options then yes it looks like you will be out of luck. Requiring accountability for who is making requests is not something that is out of the ordinary, most services online that offer 3rd party APIs usually require some for of OAuth token or similar authentication token to access their API endpoints.
The request to “/helix/users” mentioned at the top as a sample request according to the API documentation does not require auth. So does this mean, that this call will require auth in the future? I guess so, as @jbulava writes “OAuth will soon be required for all Twitch API endpoints in the new Twitch API”. But when will this be reflected in the API documentation?
This leads me to my actual question: Is there a way to test this?
I have a tool which does lots of API calls from my server to the Twitch API. So as far as I understand I will need an “App Access Token” in the future. No problem, that’s easy to acquire.
The problem I have right now is, how to test this? I tried to pass garbage as “Authorization” in all of my request headers. Expected to get an error from the API. The Twitch API responds with the requested data regardless of what I send in the “Authorization” header. So it seems I have no way to test if my code is ready for the upcoming changes.
When you specify a valid auth header, it’s valid so no error is returned.
But you do get a higher rate limit, currently, with just Client ID you get 30 requests, with any valid auth token you get 800 requests. So in short, check the response headers for the update rate limit values.
@BarryCarlyon Thanks, that helps a little bit. I’ll implement some tracing that checks if the rate limit of all my calls is returned as 800. That gives me at least a chance to figure out if I correctly implemented my token acquisition and caching system.
Still find it strange that you can post garbage data to the API and it silently ignores it
I have a website I manage for another streamer based on a template (so I have no idea how to implement any changes into this codebase) that runs entirely on GitHub Pages (so no server backend to generate new tokens when it expires) that merely shows if they are live and how many followers they have. I have 0 idea what to do cause these changes.
Well the issue with that example is a user needs to login which is completely overkill just to display public info like if a streamer is live.
Here’s the website in question https://mrsir2552.com/ and said template https://github.com/damoun/dam0un.live. It’s just a basic landing page that shows if the person is live, nobody is gonna make a user log into a basic website that just displays public info like that.
What’s the latest on this? I have just received an email from Twitch warning me about converting extensions to use OAuth, but I am currently holding off on that based on this comment.
Are we safe to leave our extensions untouched for now?
Yes, exactly. Just to get real basic info like if live and the game name, requiring a login flow is ridiculous and does not improve security when we already need to register to get a client id and secret. There needs to be some basic public stuff left in like this.
Extensions are except from the April 30 deadline if the Extension was submitted for review on or before January 31. Apologies for the confusion. We’ll have more information about steps for Extensions before the date in June.
If you are having an issue then you are mis typing something somewhere.
The curl command is just an example, and you should move from it to a curl interface in the programming language you intend to operate in. Don’t get bogged down in curl.
The ' on the end of the whole command is the wrong kind of ' and it’s not closing the URL
Really thanks for the help. I make it working by giving the right '
But I observed one thing. If I give wrong app token, still I’m able to get the streams. Twitch isn’t validating the app token in below request. Do they validate app token after April 30th?
You’re sending a Client ID with your request, so right now that request will work regardless of if the the token is invalid as right now it’s just optional, and as you’ve provided a Client ID it uses that to allow your request instead. If you had tried to use just the token, then if it was valid it would succeed, but if it was invalid you’d get an error.
From the dates mentioned in the first post of this thread, you’ll need both a valid Client ID and OAuth token.
Is there an endpoint we can confirm against? I would like to send my Client-ID and Bearer token to an endpoint where I can confirm my requests will work with the new requirement? Doesn’t need to be real data… just need to make sure my http requests are setup correctly with the required header data.
Basically I want to send the correct, and incorrect, client id and watch it pass and fail.