I’m planning to build a simple extension that connects to Spotify in order to show the streamers recently played tracks. I need the streamer to do a Spotify OAuth authentication so my extension can access their data, and it’d be really cool to be able to do that all in the Extension config and never have to interact with my EBS. However, I’m not seeing how I can do this. I can’t send them to Spotify.com to do the OAuth handshake, and even if I could, I’m guessing it’s not possible to callback to an extension.
The only way I can see to do it is create a frontend for my EBS, have the streamer visit that and OAuth with Twitch then OAuth with Spotify. Config page will have to hit my EBS with the streamer details and either load their config options if they’ve done the Spotify connection, otherwise present a message saying they need to visit the EBS frontend before they can use the extension.
Given that right now Twitch doesn’t provide a way to store configurations Twitch side, you need to do the oAuth dance and store the oAuth in your EBS anyway.
You should be able to redirect a user to Spotify from the configuration panel of the extension, or open a popup (again from the configuration panel) that does the relevant dance.
So I think I misunderstood what I could and couldn’t do in regards to linking offsite in an extension.
Let me get this straight.
I can have the config page include a link that takes the user to the Spotify OAuth landing. (And this will be loaded inside my frame on the Extension config page?)
When they approve the OAuth, can I have Spotify callback to a route on my EBS like (/verify) with the oauth goodies.
Then I can have my EBS redirect back to the Extension config page. This works with localhost, but how do i know the URL of my config page once the extension goes live? Does twitch provide a static location on the CDN where the assets are stored?
And then i just need to whitelist Spotify.com and my EBS url and it should be ok in terms of approval?
If that works that’d be sweet. Would appreciate further clarification the points there if you don’t mind.
I think you should be able to launch a popup actually.
Best to test and see.
Config panels often have to auth users with other systems, so it has to be done to support your application.
Or if Spotify support implicit auth, where the code is passed back a a #code=r58784758475847587 and tend to be less lenient on enforced redirectURI’s sometimes (IE: Your app does not use a server, such as a client-side JavaScript app or mobile app. This approach does not require a server that must make requests to the API. to nab some copy from the Twitch Docs)
Or back to the dashboard page itself
Hmm that’s a bit complicated actually… It’s in the form of
Unsure, what we have described here makes sense and appears to meet the guidelines but may be rejected, I’m not Twitch Staff.
Personally, two points:
a) What is your extension going to offer that is better than the Spotify Extensions that already exists Creator Dashboard (hmm I’m sure there was two, there is only one now)
2) When I need to pull now playing from Spotify, I usually tell people “link a last.fm account to your Spotify in the Spotify Client and just give me your last.fm username instead”
Making a spotify tracker is largely just because it seemed like a good project to test the system, in that it has a bit more complexity than “pull data from EBS and display on overlay/panel”. I am certainly learning stuff in investigating it.
For example, totally didn’t know that I could pop OAuth in a new window, have it do the dance, then have that window close and callback to the window that opened it, all in javascript. Was confused when you said launch a pop-up as to why that would be a good idea, but google helped me out.
With that in mind I think I should be able to have a crack at building this now, thanks for your help!
Hate to resurrect a dead thread here, but I feel like it pertains to a situation I’m facing. Pop-ups cannot call back to their opener in this case, since an iframe can’t be accessed by a child pop-up window (violates security issues and most browsers prevent that). Without redirecting back to a Twitch URL, how do you do this? Ideal flow:
User clicks OAuth and OAuth opens in a pop-up
Successful authentication redirects to EBS (/auth/callback or whatever)
The EBS page that renders closes itself and gets the auth data back to the main window that opened it
Alternative to #3: If #3 can’t happen like that, then how do you go about saving the auth credentials in the EBS and tying it to the proper user on the back-end so that the client-side can retrieve it later, without also having the user ID (either opaque ID or their actual Twitch ID) to associate with the credentials that are sent as parameters in the OAuth callback URL (since the redirect URI can’t have additional parameters that we could supply–because most OAuth schemes don’t allow parameters in the redirect URI or wildcard URLs, it has to match what’s in their whitelist exactly)??
Hahaha “that’s a long sentence”—actually laughed out loud. Thanks for the help. I was unaware that messaging worked through iframe/popup communication like that. Thank you!
@BarryCarlyon that’s correct, and I’m aware of that policy. This doesn’t apply just to viewers, having to redirect broadcasters back to Twitch’s config URL for OAuth is less than ideal as well, because it almost feels hacky, having to tack on extra parameters to a URL I don’t have ownership over. Thank you for looking out though—much appreciated!
then you just need to do oAuth and whitelist id.twitch.tv for your config panel. You should need to add one any extra parameters. You can pass information using the state parameter.
or whitelist your EBS,
link from your config to your EBS,
build a state payload, store that in your DB,
add a state parameter to the redirect to twitch to ID the payload.
And twitch passes the state parameter back to you on the code return.
Do what you need and redirect back to the panel
