I’m working on getting EventSub up and running via webhooks, and I have a few questions that I don’t see answers to in the docs.
If my server fails to give a 2XX in a timely manner, Twitch will revoke the subscription with notification_failures_exceeded. But if this happens because my server goes down, the revocation message isn’t exactly helpful. Is there a way to know about the revocation other than just fetching the list of current subscriptions and having to deduce which ones don’t show up?
I know Twitch will revoke with authorization_revoked if a user revokes the auth token or changes password, but is that also true if the user simply authorizes a new auth token for my app with different scopes? I assume I have to re-subscribe to the desired message types with the new token, right?
I understand the load-balancing and distributed processing benefits of conduits, but are they also useful for not having to manually re-subscribe to every event type any time my server goes down and comes back online? I had assumed it would allow me to just reconnect to the conduit and automatically have all my subscriptions ready to go. However, I don’t actually see that described in the docs, so I think I must be mistaken. Can someone clarify how that works? Do I always have to re-sub to every subscription for every user every time?
If your server is down then no, becuase your server was down.
So are “your service restart” you need/should sanity check your subscriptions.
No.
Becuase a user prior authed access between the clientID and a user.
Generating a new token just generates a new token which may add more scopes between the clientID and the user, but won’t remove scopes that the new token doesn’t have.
So:
User auths with a/b/c
User later auths with b/d/e
You have a/b/c/d/e for the purpose of eventsub. (when in webhooks/conduit land)
Given here you are on about webhooks, your app access token is used to create subscriptions and Twitch checks the full list of scopes that were granted between clientID and the user, not the “most recent token” when checking if your clientID can subscribe to a given topic/type.
Not for webhooks no, if you only have one callback.
Conduits doens’t really give you any subscription benefits here. (sure the shutdown time might be a little longer, but twitch is generally super liberal before it 'nixes webhook subscriptions so a conduit doesn’t give you much more space/time overall), and even then at “service restart” in a one shard land you should still sanity check your subscriptions are what you want when you reconnect the shard(s).
If you only have one callback URL/server, then the benefits of a conduit for webhooks are less then just going straight in the first place.
Given here you are on about webhooks, your app access token is used to create subscriptions and Twitch checks the full list of scopes that were granted between clientID and the user, not the “most recent token” when checking if your clientID can subscribe to a given topic/type.
This makes sense, I keep forgetting that the subscriptions themselves are operating at the application token level not the user token level.
However…
Generating a new token just generates a new token which may add more scopes between the clientID and the user, but won’t remove scopes that the new token doesn’t have.
This is not at all what I expected…So in order to get a new user token with fewer scopes, you have to actively revoke the current token before authorizing the new one?
This brings up further questions that I have about tokens:
I was under the assumption that you could only have one active user token at a time for a given user. If they re-auth, they get a new token and the old token doesn’t work anymore. Is that not true?
Does that new token then take on the scopes of the old token PLUS the scopes requested for the new token?
If that assumption is false and the user can actually have multiple active user tokens for my app at once, do I have to do anything special to manage those old tokens or can I just ignore them and use the newest token?
Lastly, is there a place in the docs that describes all of this that I somehow missed? If not how are we supposed to know that it works this way? Or is this standard OAuth behavior that I’m just not well aware of?
If you only have one callback URL/server, then the benefits of a conduit for webhooks are less then just going straight in the first place.
This is great to know. I’ll continue without conduits then until I actually have a use for the sharding and load balancing features. I just wish there was an easier way than having to send each subscription one by one. When there are a lot of subscriptions to make, such as for a multi-channel chat bot using webhooks for chat messages, it takes ages to “rejoin” all the channels on startup if the downtime was long enough to drop subscriptions.