Only getting ERR_BADAUTH from LISTEN PubSub request


#1

I’ve checked the two suggested articles related to “ERR_BADAUTH” and neither helped my problem–they are also from 2017 so perhaps out of date anyway. I’m using Node.js with the ‘ws’ and ‘request’ packages, for what it’s worth.

I am trying to listen to the custom channel points pubsub topic. I’ve successfully registered an application on the dev site and gotten a Client-ID and Client-Secret. I also have successfully connected to the pubsub-edge.twitch.tv site as well as received an oauth token from the id.twitch.tv site, using the Client-ID and Client-Secret from my registration as well as all of the scopes listed on the pubsub documentation. However, after all that is done, sending a LISTEN request through the pubsub connection still results in a RESPONSE with a ERR_BADAUTH error type.

I’m not including the “OAuth” in front of my token when sending it.

An example of outputs I get from running my program:

[open] Connection established.
-> PING
<- PONG
Successfully authenticated (token, 4 scopes). Refreshing token in 5322s.
Sending data:
{
“type”: “LISTEN”,
“nonce”: “nonce”,
“data”: {
“topics”: [
“channel-points-channel-v1.channel_id>”
],
“auth_token”: “token”
}
}
[message]
{
“type”: “RESPONSE”,
“error”: “ERR_BADAUTH”,
“nonce”: “nonce”
}

I can successfully connect to the pubsub server, perform PING/PONGs, get my OAuth, but I cannot for the life of me figure out why the LISTEN request always fails. I’m new to OAuth stuff so my apologies if the solution is trivial. I have spent several hours this weekend with various print statements and rereading the documentation and other forum posts and couldn’t figure it out.

Sorry the json output formatting is poor.


#2

Just as a checklist for you to get down to the problem:

  • You made sure your token is valid by querying the API endpoint https://id.twitch.tv/oauth2/validate
  • You have the necessary scope channel:read:redemptions
  • AND the OAuth key with the necessary scope that you got is authenticated by the owner of the channel that you want to subscribe for points redemption events (This might be the crucial failing point I assume here)

#3

That is the endpoint that I use to validate with.

I have that scope attached to the token.

However, I definitely did not authenticate the token with the channel owner (me). I don’t even recall reading that as a requirement-- is that mentioned in the PubSub documentation page? If so then I missed it completely. If it’s not on there, how would I go about doing that? For what it’s worth, my account also is the one I signed in with to get the Client ID and Client Secret.

Thanks for the help


#4

You need to use a token that represents a user.

You used an App Access token that represents no user at all, it’s a key that represents only a ClientID.

Yes, the docs don’t explicit say it needs to be a User token, but it’s implied. Since the userID for the topic needs to match the userID of the token used.

Otherwise there is nothing to stop you generating a topic and capturing, say, Lirik’s subscribers over PubSub for example.

Anything that uses a scope, userID, or “protected data that needs a scope” will require a Token that represents a user.

It’s mentioned here:

In the description about token types

It’s touched on here:

This is an example request for Bits events. It listens to Bits events on channel 44322889. The authorization scope is specified when you generate the OAuth token using our authorization flow; see the Apps & Authentication Guide.

Raised as a documentation issue at


#5

So what is the status of that github issue tracker anyways? I know its christmas now but as Ive seen it there is just one (1) issue resolved and that was just a little template thing for the github repo. Are there any plans to address any issues raised there in a short amount of time, asking subjectively @BarryCarlyon for your opinion as you have been active there.

Also I am new in this forum here, kinda not been so active at least but speaking of experience from forum posts about bugs here is there any work done in a short amount of time at all or does it take a lot of time till anything gets resolved if you look at the past issues raised here.


#6

@kiznal Also you mentioned you looked in the forum and such. I used some search on google and came relatively fast to this post here on the forum: Introducing the Channel Points redemption PubSub topic there is some insights about that you need to have a token by the channel owner, and thus a user token to begin with :slight_smile:


#7

No idea. I’m not Twitch Staff. Hopefully Twitch will be taking a note and fixing reported things. But it’s new to Twitch’s Work flow so shrug

It’s only recently been created and it is Christmas break.

Also depending how Twitch operates internally, it takes time to work issues into their sprints/time lines unless it’s a “shits on fire and it’s completely broken” type of issue.


#8

When it comes to bug reporting you usually wont see updates from Twitch on the subject either. The issue will be passed to the appropriate teams, given a severity and place in queue, and you may not hear anything back until one day whatever the issue is it’ll just be fixed, so just because issues on Github haven’t been updated doesn’t mean they may not already be in the process of fixing, or already fixed.

As for PubSub docs not mentioning token type, there are many places in the docs where the difference between User tokens and App tokens aren’t specified because it’s one of those common sense things implied by how tokens work, this is not just a Twitch thing, it’s standard OAuth usage with if you want to access user info, you need to explicitly ask that user for permission to do so, where as app tokens don’t require any user interaction at all. I’d have to double check but I’m pretty sure the docs do explain that App Access tokens for server-to-server requests, and not for anything on behalf of a user such as accessing their private data like email, subs, etc…


#9

App access tokens are meant only for server-to-server API requests and should never be included in client code. in the token types section yes -> https://dev.twitch.tv/docs/authentication#types-of-tokens


#10

Thanks for the inputs! After reading these posts (multiple times) as well as scouring the Twitch docs and and docs a few other places, I’ve finally gotten it to work and read custom reward redemptions. Figuring out how to correctly get the tokens was the hard part, implementing was not. You can close this thread now, and thanks for raising the docs issue on the github :slightly_smiling_face: