Update Beatport plugin to use API v4

[Samik081]

Description

Fixes #3862

As Beatport had killed their API v3, the stock beatport plugin does not work anymore. It is also currently not possible to request the access to the API "normal" way (by using your client credentials or API token generated by Beatport, see the linked issue #3862). I have found a workaround and was able to update the code to use the new specification of API v4.

Currently, to use the plugin, you need to obtain the access token yourself. As soon as Beatport allows official way of the authorization, I am willing to update the code to use it, whether it be client_credentials grant or any other OAuth2 flow they are now presenting in the API docs.

I have also created a beatport4 plugin that uses the above code and added there an unoficcial way of acquiring the token (not part of this PR). To see more details, please see the plugin repository: https://github.com/Samik081/beets-beatport4

Beatport Authorization

Steps:

1. Add beatport plugin to your beets/config.yaml plugins list
2. When the first import with plugin enabled happens, you will be prompted to paste the access token JSON
3. Obtain a token (currently rather not possible official way, see the description above) in a following format (those two fields are required):

{
  "access_token": "XXX",
  "expires_in": 36000,
  ...
}

4. Paste it to the terminal (or beatport_token.json file next to your beets/config.yaml - you can check the path by running beet config --paths command)

P.S I am not a daily python developer, so don't hesitate to point out anything you think looks ugly :)

EDIT 10.09.2022

Removed authorization part that uses user credentials, Beatport swagger-ui client ID and authorization_code flow, see the comments.

EDIT 16.09.2022

Edited PR description so it reflects the current code (removed part about Beatport unofficial authorization).

[wisp3rwind]

As Beatport had killed their API v3, the stock beatport plugin does not work anymore. It is also currently not possible to request the access to the API "normal" way (by using your client credentials or API token generated by Beatport, see the linked issue #3862), so I have found a workaround that uses public API client ID used for Beatport docs frontend and updated the code to use the new specification of API v4.

I understand that the current beatport situation is frustrating, but (assuming that I understand correctly what your workaround consists of) I'm strongly opposed to merging this branch: Abusing the docs client ID in this way sounds like a surefire way to guarantee that beets will not be granted a proper client ID ever again (when and if they re-open registration). Obviously, it's your business to host a third-party plugin under your profile.

[Samik081]

As Beatport had killed their API v3, the stock beatport plugin does not work anymore. It is also currently not possible to request the access to the API "normal" way (by using your client credentials or API token generated by Beatport, see the linked issue #3862), so I have found a workaround that uses public API client ID used for Beatport docs frontend and updated the code to use the new specification of API v4.

I understand that the current beatport situation is frustrating, but (assuming that I understand correctly what your workaround consists of) I'm strongly opposed to merging this branch: Abusing the docs client ID in this way sounds like a surefire way to guarantee that beets will not be granted a proper client ID ever again (when and if they re-open registration). Obviously, it's your business to host a third-party plugin under your profile.

Hey @wisp3rwind, thank you for your input!
I agree with you - this is not the way it should be done in official repo.

I am going to delete the username/password configuration, and code responsible for the authorization, but leave the option to paste the OAuth token. This way it is not going to be dependent on docs' client ID.
I think using OAuth token provided by user is fine, isn't it? In the future, this is still going to be a decent fallback method if the authorization fails.

The rest of the code is not related to the "workaround" and could be easily used now (by passing the access token if the user has it) or in the future by just implementing Beatport4Client._authorize() method and passing configuration options.

What do you think?

[Samik081]

I have made the refactor I mentioned in the previous comment, but I'll leave the PR description for a little longer to keep the track of what happened in the PR.

EDIT: 16.09.2022

I have updated the PR description, so it now describes the current state of the code. More info and code containing authorization part is still available in my repo tho.

[JOJ0]

Hi @Samik081, since I'm about to update the state of open beets PR's and try to tidy up a bit I have set this one back to draft state. I think there is some currently unsolveable things that unfortunately is out of our hands with the new Beatport API and no way this plugin can be fixed correctly. Please update this PR if you think it's ready for a final review.

BTW I much appreciate your work and will continue to report and contribute at your own repo's version of the plugin because I often just need Beatport because I can't find stuff anywhere else.

I hope you don't mind this change to draft and get back to us with any questions. Cheers!

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.