Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OAuth support for accessing Web API endpoints #143

Merged
merged 2 commits into from
Jun 7, 2017

Conversation

kingosticks
Copy link
Member

@kingosticks kingosticks commented Jun 1, 2017

Fixes and tests for @adamcik's original branch.

Still need to consider (from #130):

  • check for id/secret from spotify_web, though that would mean making the new ones optional?

kwargs.setdefault('headers', {}).update(self._headers)
response = self._request('GET', url, **kwargs)
result = self._decode(response)
except Error as e:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably catch a more specific error? Also do we want to log this just as debug?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking could raise and catch OAuthTokenRefreshError and a OAuthClientError exceptions. And I agree, these want more visibility, error level doesn't seem unreasonable to me.

@kingosticks
Copy link
Member Author

kingosticks commented Jun 6, 2017

I'm done here, any comments on the latest commits @mopidy/mopidy? Happy to remove/edit the warning message if anyone has a better idea.

@adamcik
Copy link
Member

adamcik commented Jun 7, 2017

Not sure if caring about the credentials between the versions is the same makes any sense? Other wise this looks fine :-)

@kingosticks
Copy link
Member Author

I don't follow, between versions of mopidy-spotify? Which credentials?

I was thinking maybe it should check the credentials provide the particular scopes we need? Did mopidy-spotify-web previously request whatever scope is needed for search and images or did you have to add that?

@adamcik
Copy link
Member

adamcik commented Jun 7, 2017

As in spotify.client_* != spotify_web.client_* probably not really mattering. If that clarifies things a bit.

For the scopes we currently request enough, but as soon as we start moving away from libspotify more whole sale this will start to matter more. And since there are already a bunch of tokens in use we just have to figure out how to migrate people somewhat nicely when the time comes.

@kingosticks
Copy link
Member Author

kingosticks commented Jun 7, 2017

EDIT: reworded

I thought it was necessary for both extensions to use the same set of credentials. If the auth bridge is used multiple times, I thought different credentials were obtained each time but only the last ones obtained are valid. If this is incorrect then I'll just revert that last commit.

@adamcik
Copy link
Member

adamcik commented Jun 7, 2017

You can have as many tokens a you like, and it makes no difference if there are separate ones for the two plugins. What could work is having spotify use the one from spotify_web if it's own value isn't set. But I think it makes more sense to make the spotify one required forcing people to fix this.

@adamcik
Copy link
Member

adamcik commented Jun 7, 2017

Other thing we could do is look over the scopes and reconfigure the defaults the oauthclientbridge requests, potentially reducing the migration required later?

@kingosticks
Copy link
Member Author

kingosticks commented Jun 7, 2017

You can have as many tokens a you like, and it makes no difference if there are separate ones for the two plugins.

OK. I'm going to revert that last commit and squash the rest.

What could work is having spotify use the one from spotify_web if it's own value isn't set. But I think it makes more sense to make the spotify one required forcing people to fix this.

Agreed.

Other thing we could do is look over the scopes and reconfigure the defaults the oauthclientbridge requests, potentially reducing the migration required later?

I think this would be worthwhile. Getting playlists through the Web API is probably the next most pressing thing to fix so making sure we have all the playlist-* scopes would be nice.

EDIT:
For reference, we currently have:

  • playlist-read-private
  • playlist-read-collaborative
  • user-library-read
  • user-follow-read

Use specific OAuth exceptions, handle them and json parsing in one place.

Add new web API authorisation steps to the README.
@kingosticks
Copy link
Member Author

Ready to go! Do we need @jodal to make and upload a release?

@adamcik
Copy link
Member

adamcik commented Jun 7, 2017

I should have access at least, but haven't done this in ages. I'm kinda liking the idea of automating away all of this for everything in the mopidy org, but that is well beyond the scope of this PR.

I'll go ahead and merge this as step one at least, and I might have time/energy to look at doing a release this evening.

@adamcik adamcik merged commit 42a4365 into mopidy:develop Jun 7, 2017
@pgrenaud
Copy link

pgrenaud commented Jun 7, 2017

Good job on this PR. 👏 I'd love to see a release today! 😄

@kingosticks kingosticks deleted the feature/oauth branch June 7, 2017 17:14
@jodal jodal added this to the v3.1 milestone Jun 7, 2017
@jodal jodal mentioned this pull request Jun 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants