Worried about Review Process

Well you are building an extension.

Not a chat bot.

is an example of setting up some code to respond to the onAuthorized callback.

and demonstrated in the “profile extension” example I already linked to.

Good point. I had that in place so they could log in via chat… but seeing as that’s not what I want anymore… I’m looking to change it.

Does what I propose make sense? If so, how do I set up the code to listen out for a user authorizing the extension using websocket or AJAX?

Also, will it automate the request every time it loads up? Or only the first time someone clicks that authorize button?

I already showed you how

It’ll prompt once, unless the user disconnects the extension/other criteria causing a disconnect.

Can I just grab the AJAX part of this?

 method: 'POST',
        headers: {
            authorization: 'Bearer ' + window.Twitch.ext.viewer.sessionToken

The coding software I’m using is quite bespoke, and as I said, I’m very new to all of this.

AjaxExample

Can I set this up as a websocket? That would be my preference.

The Extension front end will make a HTTP whatever to your Extension EBS.

The Extension EBS will then grab the JWT and then from there you can do what you want

I use the prefix of “Bearer” in my authorization header from Front end to EBS as thats my preference, but it’s the Extension JWT not an oAuth token.

The Ajax part of the example extension is making a call from the HTML/JS/CSS Extension frontend to the extension backend

Sure an extension front end can make a websocket connection to a Extension back end, as long as that socket is over SSL

OK… next question. Do you know where I can get someone to do this for me? :rofl: I’ve asked my colleagues to have a read through of what you’ve said, and almost none of it is making sense to us.

We do not have backgrounds in the web side of things, so it’s beyond our abilities.

You say we need a backend server, but we have no idea how to implement such a thing. Even the Twitch Documentation just seems to say “Do it!” as though that’s a tutorial. I have no idea if I need to create an HTML file, a php file, a js file… anything. It just says “Backend”.

We’re aware that (for us) the backend needs to be in place for the sole purpose of allowing us to decrypt a User ID, and that we can obtain the genuine ID when the user grants permission, but have no idea why Twitch have a random ID generated for extensions (which we have to convert into a real ID), but not anything else.

We’re aware that (for some reason) we have to host the decryption process, instead of sending an AJAX to Twitch and instantly getting the result, like we’ve done with every other process.

I’m aware that we submit the ID to the backend using:

window.Twitch.ext.onAuthorized(function(auth) {
  $.ajax({
    url: '/<some backend path>',
    type: 'GET',
    headers: {
      'x-extension-jwt': auth.token,
    }
  });
});

But again find ourselves stuck at the fact that we have no idea how to create the backend.

I’m aware that I need a backend, but I honestly do not understand why.

I’ve been trying to get my head around this for 2 months. We’ve created a product that is perfect for Twitch, and we’ve never seen anything like it on Twitch before… but we’re stuck now because Twitch frowns at people having to type 1 word into chat once per stream.

I understand that skipping this step would be a good thing, but I have to jump through a dozen hoops just to save people 3 seconds.

You can join the third party discord

And post in the #looking-for-devs room

Can you tell me why I need to set up a EBS for this, rather than Twitch hosting said decoder?

There isn’t an api for this, such as GET https://api.twitch.tv/extensions//current_channel?

I feel as though I’m just missing the initial step, and if I can get my code to recognize the window.Twitch.ext.onAuthorized, I’d be able to do the rest somewhat easily.

You cannot call the Helix API from the front end as you cannot generate an oAuth token to call the API with without leaking your Client Secret.

Is there a size limit to the front end? As so far my extension is entirely front end, and I’m able to generate a Bearer token and contact the api without issue.

My code is also minified, so I’d have thought it’s quite difficult to get the Client Secret, but I guess there’s something I’m missing.

So just to clarify… even if there were a way to contact the Helix API from the front end, there’s no path that would allow me to find out the current user’s ID and the channel’s ID. Correct?

So this means you are leaking your Client Secret! Which is against the developer agreement.

The exception is using implicit auth in your extension, which would mean users are logging in twice.

Code being minified still means your client Secret is in the file in the clear and easy to steal.

If you did a second Authentication loop, and got an implicit bearer, then you can lookup the user by bearer.

But you already have the users UserID from onAuthorised.

If you continue with your code as is, you are in violation of the developer services agreement, and your extension will be denied

I had it generate the token purely because the remote app had that code in place, so did a copy/paste.

It’s not actually doing anything, so I can take it out without issue/breaking anything.

Sorry, when you said “You can’t do it” I thought you meant it was impossible, not that I wasn’t allowed to do it :rofl:

So it’s just getting my code to spot the onAuthorised call from Twitch. I tested it yesterday in the developer rig, and I didn’t get any response from it… so I figure I’ve done something wrong.

I uploaded your server.js to my host so that I can access it. Would it simply be a case of pasting your script.js code in to my front end, and getting the two to contact one another?

We made a similar thing.

Just one question:
How did you ever make the extension communicate with the streamer’s app without any EBS?

Probably this makes some things clear:
EBS is a service running somewhere in the internet where your Extension (and probably the app) connect to - mainly for exchanging data.
In our case the EBS is a NodeJS service running a socket.io based messaging proxy to route messages between extensions and the game application on streamer’s side.
The EBS can be anything. A NodeJS app, a C++ program, for some situations even a REST API or alike. But your requirements sound much like a stateful backend service would be required.

You will want to do the following on extension<->EBS side (spoken for a socket io or similar implementation):

  1. Connect Ext -> EBS
  2. Send JWT -> EBS
  3. EBS verifies JWT signature to authenticate
  4. EBS will somehow map the socket to this extension into a “room” (that groups all viewers and the streamer together)
  5. whatever you need for communication can start now.

The Streamer’s App will connect to the same service but will not send a JWT but instead send a bearer token (it needs to generate on behalf of the streamer) and the EBS will verify this and get the user ID from the API

onAuthorised is called on every page load, so not sure what you are doing wrong

The github example I linked to is a fully working extension.

With a Readme that covers how to get it up and running to play with/test

The backend can be replaced with a backend in any language, and it covers the “simplest” method to get the users profile from an onAuthorised callback

Send the JWT to an EBS Rest Endpoint
EBS extracts the userID from the JWT
EBS middleman’s the request to Twitch, using an appropriate oAuth token

Hey @Firesplash thanks for the message.

The app we’ve made creates an online room named after the broadcaster. Once I know the channel’s name that the viewer is on, if they’re using the extension, it simply connects to that room.

Can you confirm whether or not the EBS is just a single file, or if it’s an actual program that needs to be running all the time? As mentioned, I’m new to this side of things, and so far I’ve simply been able to send an AJAX to Twitch, and receive the info I’m looking for. I was hoping that I could just use an ebs.js file, hosted on my website that will act as a decryper… So I could send the OpaqueID to that and receive a JSON as a response.

Instead, I’m getting the feeling I need to have an actual program running constantly, which is even further outside of my wheelhouse.

Yeah, we’ve taken your example, and followed the guide as best as we could. We assume “In the ebs folder copy config_sample.json to config.json” is asking us to rename the file, but we weren’t 100% sure.

Also the last step: “Change the https://theURLtoMyEBS to the URL of your now running EBS” confused us, as it doesn’t tell us where we’re meant to change the url, let alone where the URL is meant to be aimed at, especially as we appeared to be running it via our command prompt.

In any case, running it through the Twitch Developer Rig, we were able to get the front end to run, but the backend was throwing up a lot of errors.

We then shifted our attention to the colour changing example within the Dev Rig, and managed to get that working, but we’re hitting walls regarding how to change the path of the backend.js.

Gotta say, for an example code, they’ve made it incredibly hard to reverse engineer, with variables being converted into other variables, then finally getting called. I understand that for an actual program, but it seems like a strange choice for a tutorial/example.

The EBS, is essentially a server that runs as a web address you define.

I cannot tell you what the URL is as I don’t know where you are hosting your EBS from.

Additionally all communications need to be over SSL, so you need a SSL certificate. I generate mine from letsencrypt.

Copy or rename, either way you need to change the value in the file, to where ever you put/host your EBS at.

var my_ebs = ‘https://theURLtoMyEBS’;

becomes

var my_ebs = ‘mywebsite.com is available for purchase - Sedo.com’;

Of where ever your EBS is hosted at

It’s an example I wrote which assumes you have basic knowledge of javascript and how to make http requests to the API. So it shows how to bind existing knowledge together to make a working extension. It lacks comments as I’ve not gone back to add more comments everywhere.

The front end script literally does one thing,

  • grab the JWT
  • post the JWT to the EBS
  • grab the response from the EBS
  • draw a table from that response

The server is a bit more indepth and has a few more comments.

  • Generates an App access token to use
  • Waits for a HTTP Post
  • Grabs the JWT and if valid,
  • Takes the userID and app access token to call the Twitch API
  • Pass the whole json blob back to the front end

So if you are building your EBS in nodeJS you can just cherry pick out the whole server but probably do something different at line 124 after you’ve got the users profile from the Twitch API

Yeah example illustrates how to pass pubsub messages from one place to another without a EBS iirc correctly. An example that generally wouldn’t be used in production.

Depends what language you write your EBS in.

If it’s written in PHP, the PHP-FPM would be running all the time.
If it’s nodeJS then your server.js (like my example) would be running all the time

For example.

It needs to always be on/able to respond as you don’t know when it will be called.

An EBS is essentially a website.

You wrote the colour wheel example? That’s the program I’m referring to that seemed overly complicated. Not the profile_extension. That appears to be quite straight forward, almost plug and play. As I said, I couldn’t get the backend to actually work, but I was missing the var my_ebs… which is key :smiley:

There are two examples… one which is a “simple” colour wheel changer, and another which is a color wheel changer that is related to pubsub.

I’ll give your example another go.

If I can get the backend to send over the channel id and user id to the front end javascript, then convert those variables into something my program can actually register, then I’m done. I’m so close I can taste it… but it’s been a long and stressful process.

Thanks for clarifying this. That’s a weight off my shoulders.

So that means you ALREADY HAVE a service running somewhere online where the extension (and the game) connects to?
This is literally the best place to implement all the server side code - including JWT validation. This service CAN BE your EBS if you want.
EBS is just a common name. It means “Extension Backend Service”. You could also name it “Game Server” or probably use a “REST API” as EBS (debending on your use case).

An EBS can be a fingle file (process) or a complex application. Depending on what you want it to do.

You are a GameDev,r ight? Think of your Extension being a game client for a Lobby-based game, your EBS would be the game server where the client connects, authenticates (using the JWT in our case) and gets assigned to a room (lobby) where all the other clients in this Lobby ID (twitch channel) are connected.

Hopefully I was able to make things clear.

Edit:
Just an idea for handling: At connect time you do already know the channel id from onAuthorized callback. If not (jmeans the viewer did not accept ID share yet), simply do not connect but ask the user for permission. This has to be achieved in JS on the extension side.

That’s what I originally wanted to do, but the unfortunate thing is that the game is run on the streamer’s device. The extension is obviously run on the viewer’s device.

Let’s use myself as an example. I stream using my app, and it creates a multiplayer room called “and4d”. You then go to my channel as a viewer, and load up the extension. In a perfect situation, the extension would simply join the room “and4d”… but the problem is that the extension doesn’t know the name of the streamer, so it doesn’t know which room to connect to.

The two programs can not contact one another until I know both the ChannelID and the UserID (for grabbing the correct data from the database).

However… you’re probably correct. If the onAuthorized callback confirms the ChannelID, I could just have the code join that room, and then send the OpaqueID to the application, which can then return the actual ID, seeing as I already have a bearer token, etc generated in that program.

Now… doing that is another problem :sweat_smile:

*EDIT - However, having said that, when a user joins a room, they need to provide a name… which at the moment is their Twitch Alias… so that won’t work :frowning:

Yup. Name a 2D game and I can build it without much hassle… but this has seriously thrown me through a loop :rofl:

Ideally I’d just need an onAuthorized event which triggers an AJAX action contacting my backend.js hosted on my site, but I’m brand new to Javascript, so figuring out how to get it to work well with my programming software is a bit of a challenge… to say the least :slight_smile:

Toss the opaque id. opaque means not transparent. Unable to look through. Just like Steel. No X-Ray.

onAuthorized gives you access to ChannelID and Twitch-Users ID for the extension instance (the running extension within the viewers browser).

If you need the name, let the game client (or server) look it up using it’s bearer token against helix’ users endpoint

And don’t forget about rule #1: NEVER trust a client.
If you want to make sure that the incoming connection to your server actually is the use, who it claims to be, pass the JWT you got via “token” from onAuthorized to it and validate it on server side:

This is enogh information given to anyone who really WANTS to understand it.
You are repeatedly asking the same questions that get answered again and again. It looks like you’re not really investing time into reading and trying suggestions and docs.

I am not a WebDev, too and I’m unfamiliar with Javascript. I used to work with C# so JS is like my biggest enemy (except c++). But I invested a few hours of reading and testing - and the basics you need for this are definitively learnable for anyone who has a absic understanding of coding.

Try it hard. It will work.