I have written a web sources script for spotify.com, but I'm facing a very annoying problem:
Due to the fact that the API for Spotify uses OAuth 2.0 there is the indispensable need for using HTTP request headers. Even when using the Client Credentials Flow you must provide atleast the Bearer Token in the header (after authorization).
Actually I solved the problem using an wrapper which is doing the authorization challenge and serving the Spotify API on localhost. In my opinion this is neither a neat solution nor a very portable solution.
As the Discogs Web Sources script already uses an OAuth mechanism, there seem to be some of the logic already implemented in Mp3tag, but not accessible for Web Sources scripts in general. Or am I missing something?
Is there a possibility to implement either the option to specify HTTP request headers manually (so one can specify the Bearer token after requesting with cURL e.g.) or a basic OAuth configuration and workflow for Web Sources scripts?
Yeah, that's exactly how this would be supposed to work. I would hand over the responsibility of app creation (it's not that complicated) to the user as it is much easier than to go through an application review process for generic high-usage API keys.
If I remember correctly the OAuth 2.0 flow of the Spotify Web API is fully compatible to the RFC 6749, therefore the implementation of a generic, service-independent flow should be enough.
Doing that would also doing other scripts for web APIs relying on OAuth 2.0, e.g. Soundcloud or musixmatch.
I am interested in developing a web script for a private source which also uses a Bearer token as an HTTP header. Unfortunately they have disabled the access_token query parameter. It would be great if there was an option like: