Sending permissions_received in oauth_receipt broken

Extensions
1

I am successfully getting the OAuth prompt and it redirects to my page where I then call window.close() to close the popup and on the server side I parse the JSON scope parameter and then PUT https://api.twitch.tv/extensions/<extension id>/<scope["version"]>/oauth_receipt?channel_id=<scope["channel_id"]> and it actually returns 204 No Content.

But then the twitch side is only loading and never finishing. In the background I can see how it says it’s active for a fraction of a second, but then it goes back to the activate dropdown. My testers have reported the same thing and I have checked the documentation Extensions Reference | Twitch Developers over and over, but it simply doesn’t stay activated.

https://i.webfreak.org/fWY4iH.png

I send {"permissions_received":true} with Content-Type: application/json and include the Client-Id of the extension and the Authorization header with a generated JWT with a exp of unix time + 24h.

Would be nice if someone who had success with this could help me with this.

Also is there some way to verify the scope or get a verified channel ID so users won’t be able to intercept and change the request and change the scope to inject false information? Right now it doesn’t really matter for my extension because the access token isn’t used to do anything important, but it seems like a security risk.

2

I’m having the same issue with this.

3

Pass the oauth you get back to https://api.twitch.tv/kraken/ to verify the scopes for the key:

{
    "token": {
        "valid": true,
        "authorization": {
            "scopes": [
                "channel_check_subscription",
                "channel_subscriptions",
                "user_read"
            ],
            "created_at": "2017-05-19T13:15:56Z",
            "updated_at": "2017-05-19T13:15:56Z"
        },
        "user_name": "SOMEONE",
        "user_id": "SOMEID",
        "client_id": "ACLIENT"
    }
}

then read authorizations/scopes check the scopes match and then do the PUT

204 No Content is correct, 204 means “created” and in some cases will contain a follow up location in headers (normally to the created responses) so there should be no “body data”

I’ve not needed any scopes yet since my privater caster applications I already have oAuth’s stored for their bots. So can’t comment on the rest (I may build a test flow for it later)

4

I am also having same exact issue. Last week the oauth scopes with activate wouldn’t even prompt up at all and now it will prompt but won’t finish even after successful PUT for oauth receipt. I think they are still trying to get oauth through extensions setup because I’ve seen a live extension that is doing oauth the ‘traditional’ way and doing through the configure page instead. Hopefully they fix it soon

5

That might have been an extension released before changing the rules and/or the go live date and/or the oauth stuff existing.

So it’s unfair to compare because as far as I can see there has been one public release of an extension post go live date.

6

Seems like twitch has fixed it now

7

yup, working for me now, thanks twitch

8

I’m getting this issue, exactly as described in OP (though using node instead). I’ve tested on my machine and on another test machine and account, the same behavior occurs in both cases.

Can’t help but feel like I’m doing everything correctly, but of course I may be missing something. Any ideas?

9

Got this working after taking some time away from my code. I wasn’t passing along the data payload with my request (I supplied the data but in the wrong place).

The entire time, however, I was still getting 204 responses from Twitch, despite not providing the data. Even with the data payload received, Twitch sends the same status code and message, which was confusing.

10

Weeeeellllllll, logically with no payload that kinda reads as “well there was an authorisation, but it wasn’t the authorisation I wanted” aka “permissions_received” being false.

11

I still maintain that it was confusing, seeing as it’s not obvious that the oauth_receipt endpoint expects anything other than { permissions_received: true } (including an empty payload).

Also, since 2XX response codes are categorically Success reponse codes, I think sending a 204 in this case is misleading: Without a payload the request doesn’t successfully report that OAuth permissions were accepted. Had I gotten a 400 for an empty payload in the first place, I would’ve known that the error was in my code.

All that being said, I do recognize that this is quite a marginal edge case for a very simple endpoint. So I’m just glad it’s working now.

P.S. Long overdue thanks @BarryCarlyon, I’ve picked up many, very valuable techniques and info from your posts on this forum.

12

Totally agreed!

o7 not a problem! Happy to help!

1 Like