SpotifyWebAPI rewrite/redesign

[JohnnyCrazy]

This issue covers the following change: Rewrite and Redesign of our Auth-Services and HTTP-Requests for the Spotify Web-API

Auth Services Web-API

Before I go into detail, I will quickly explain how each Auth-Service is working, you can find detailed infos at their Web-API docs.

• Credentials-Auth
• ImplicitGrant-Auth
• AuthorizationCode-Auth

Credentials-Auth

This one is fairly easy, it uses both, clientId and clientSecret and you just need to make a call to spotify with both values and you will receive your token. You can't access account data with it, so there is no user-action involved. This one would be suited for pure server-side applications while no access to user-data is needed. In the following I will ignore this Auth-Service, since it can be achieved with pure HTTP-Requests, no server required.

ImplicitGrant-Auth

This Auth-Service is short lived and requires user-action but will also give you access to account-data. It was designed for use on sites like jsfiddle, where you have no direct HTTP-Server and only have access to some Client JS code. The token will be passed as a hash-fragment in your return url. So, technically, the HTTP-Server can't fetch this token since hash-fragments are a browser concept and are not send over the wire. You could write some client-js, fetch the token, and redirect with the token as query-parameter. But this is hacky. Also, this would require adding localhost:XXXX to your allowed redirect URLs inside spotify (like we currently have to do it) --> Anyone can create tokens based on your clientId. This currently is the case.

AuthorizationCode-Auth

This is the perfect Auth-Service for servers. This also uses clientId and clientSecret, so this is also just a server-side Auth-Service. It requires user-action, gives access to account-data and provides a refresh token. This refresh token can be used to get a new token without having the user to login again. After the user granted access, he will be redirected to an URL where the token is passed via parameter --> perfect for an HTTP-Server.

Ideas for the redesign/rewrite

• Patch Credentials-Auth: Make it cross-platform using HttpClient
• Delete ImplicitGrant-Auth: It's not secure enough
• Major AuthorizationCode-Auth: This should be our main focus, more below
• Patch SpotifyWebAPI: Cross-Platform, replace WebClient with HttpClient

Cross-Platform

We should make the whole Web-API cross-platform so we can run this shit on linux servers and actually use those auth methods correctly :P.

This would require following changes:

• Replace WebClient with HttpClient (HttpClient doesn't provide sync methods, we need some workaround)
• Rewrite the HTTP-Server (more below)

HTTP-Server

The HTTP-Server currently is mostly messy due to the fact I took it from stackoverflow or something similar and just edited it. It will only be used for AuthorizationCode-Auth. We need to provide enough configuration like ports, bind to specific IP-Adresses, and my favorite feature: custom HTML. Currently, a rather simple message shows that authentication was successful. It would be nice to support injecting custom HTML into the response, or, even better, a custom redirect once everything is authed. The whole API is still to design, we can either go for async-methods or events like we did before.

Regarding AuthorizationCode-Auth:
We need to abstract the actual auth process in two types:

• Standalone HTTP-Server:
  This will use the HTTP-Server above. It's useful when you don't need any further HTTP stuff. You just need it once and only for authenticating.
• Custom Handler:
  Let's say we already have an ASP.NET app running. It would be stupid to start another HTTP-Server. Better: Due to the abstraction, we can implement our own strategy. We could define our own route within ASP.NET, fetch the token, and call our strategy callback.

I though of something like the following:

• An interface AuthorizationCodeStrategy
• A class AuthorizationCodeAuth which has one AuthorizationCodeStrategy
• A class AuthorizationCodeServer which implements AuthorizationCodeStrategy and handles a HTTP-Server internally

This way, everyone can make their own strategy without us having to add a dependecy to some large framework. We could even provide strategies in some other repo with specific dependecies.

A lot of text, I hope you have some input 👍
This is just the first step, if we have worked out the design-idea, we will go into details and API-design, so don't get started yet ⌛
@erinxocon @petrroll @JimmyAppelt

[petrroll]

HttpClient not providing sync methods is not a problem as you can simply block and wait on the async ones.

Sync & Async API surface

Which leads me to a question. Is supporting every API in sync and non-sync version worth it when you can easily use the async ones in a synchronous and blocking way? Yes, it's true that async versions are sometimes even an order of magnitude slower (on ideal networks, etc.) but is performance really a problem for a library such as this one?

Removing all code for async versions (either completely or at least just providing a thin wrappers that would simply wait in a blocking matter on respective Tasks's results) would vastly simplified the project and removed a lot of code duplicity.

---

I mean you don't have to await an async method. You can simply access returned Tasks's Result property and continue the same way you would if it was synchronous call.

[erinxocon]

I'm gonna bring up using Kestral again as a backend HTTP server that we can use to define our own routes and auth strategies. This can handle OAuth pretty easily and while it adds some dependencies to the app, IMO they are worth it. We can write middleware to handle all the auth for us. It might seem like overkill, but it would definitely make this cross platform as Kestral can be run on Windows, Linux, and macOS.

[erinxocon]

P.S. I tried to use the local API on my mac and it worked as well, so if we get rid of some of the windows only stuff, this could truly be cross platform.

P.S.S Fun fact, when using Spotify Connect to my Chromecast, this lib can play and pause the client which then plays and pauses the sound from the Chromecast. I have a little setup with cassette tapes with RFID stickers on them and then a tiny c# app using this lib to control spotify. Each cassette is a different playlist and it just magically plays on the TV. It's one of the reasons I want it to run on linux so badly so I don't have to keep my windows machine on all the time! Raspberry Pi Controller anybody?

[erinxocon]

https://github.com/spotify/web-api-auth-examples

[JohnnyCrazy]

@erinxocon
Just had a look at Kestral, nope, way too much dependencies. This would add like 40 DLL-Dependencies to this project. Way too much sadly :/

@petrroll
Good question, while I would like to keep them, maybe it would be a good change for 3.0 since they really are a lot of code duplication. We then need to implement ConfigureAwait(false) for sure, else UI programs will deadlock.

[petrroll]

@JohnnyCrazy Can't really see how ConfigureAwait(false) is relevant to it. Accessing Result on Task (which is what either we in thin wrappers or users in their code will do for sync variations) blocks and then resumes the thread that calls it. Therefore there's no continuation that could run in a different context (the computation never leaves current thread) which means ConfigureAwait(false) is not really applicable there.

Speaking of ConfigureAwait, I've made a PR that should address it: #106

[JohnnyCrazy]

@petrroll
If you don't use ConfigureAwait(false) and access Result directly inside an UI Context, it will deadlock. Here is a blog post describing the issue.

[petrroll]

@JohnnyCrazy Ah, I misunderstood you. You're absolutely right about that. Luckily that is solved now with #106. And frankly, that was a problem even without us blocking with Result because it's quite understandable to assume that libraries do ConfigureAwait(false) and are therefore safe to call and block.

[JohnnyCrazy]

Yes, was about time we change that, dont have much experience with async stuff yet, so thanks again! :)

[JohnnyCrazy]

I just found http://nancyfx.org/
It would add 2 DLL Dependencies Nancy.dll and Nancy.Hosting.Self.dll. It's rather small and should work very well. It's also supported on .NET Core.

@erinxocon
Do you still want to take this job? If so, I would write some small specs tomorrow :)

[erinxocon]

@JohnnyCrazy I reckon I can take a crack at it. I'm going to play around with Nancy tonight and see what's possible!

[erinxocon]

Alas my hopes of having it work with .NET core are gone for now

NancyFx/Nancy#1959 (comment)

Looks like you have to use Kestral serving now if you want to use core as Nancy.Hosting.Self isn't yet .NET core compatible. Curses!

Example using .NET 4.5:

https://gist.github.com/erinxocon/f55035b2967c9d12a0c7c407a09a11e7

Edit: running that example does require an elevated instance of VS studio, or approving a UAC prompt. I think that might mean that using the lib will require a UAC prompt if we implement self hosting in this library. Or maybe not, I don't really know.