Musixmatch token persistence

[Eimaen]

Hi, @skuill! I really like your repository, as it provides an extensive and reliable way to retrieve texts from different sources simultaneously. Great job!
As a maintainer of MusixmatchClientLib, I'm always interested in how the library is used, and want to point out some nuances of its usage in your project. It's a suggestion, so feel free to just close the issue tho.

In your code, MusixmatchClient is initialized using new instance of MusixmatchToken, which is completely fine for generating "Desktop" context token (ref: code). However, users might stumble upon rate limits from Musixmatch API, as there's a major cooldown on token generation endpoint. After multiple tests I determined, that tokens with "Desktop" context don't expire automatically at all, so it's worth saving it somewhere on the client side and reusing it when creating a new MusixmatchToken instance (by passing it directly into the MusixmatchToken constructor: new MusixmatchToken(yourSavedToken)). I'm not sure if you save it, but looks like the token's generated every time the MusixmatchClient GetMusixmatchClient() is called.

According to the comments to the referenced method, library works as expected, as it's not designed to be used with official mxm API. I'll walk along the token generation pipeline from the official Musixmatch application to make it clear (hope this doesn't add too much to the issue).

Once one starts the official application, a new token is generated *and saved (the algorithm of token generation is already reverse-engineered, it's what the constructor of MusixmatchToken does). This token is able to do pretty much everything you need (it can fetch lyrics, fetch synced lyrics and search for songs). As the app receives token, it attempts to authenticate the user by giving them an external OAuth link (you can generate a similar link using musixmatchTokenInstance.GetAuthUrl()), that allows user to upload and sync lyrics, but requires Musixmatch account to operate.

Hope it helps debugging failed MusixmatchProvider tests (if they do fail).

Have a wonderful day!
Eimaen

[skuill]

Hello @Eimaen!
Thank you very much for describing in detail the problem of using the token. Thanks also for the awesome library ;)
I will add at least MemoryCache so that I don't have to request token generation from the GetMusixmatchClient method (ref: code).

I have another question. Are there any errors or cases when I need to regenerate the token? Maybe some exception is thrown during the authentication stage? Or we can forget about this case and reuse the generated token when launching the application?

[Eimaen]

Are there any errors or cases when I need to regenerate the token?

To check if the token is still valid, you can try searching for song (client.SongSearch), *wrapping the method in try-catch. If MusixmatchRequestException is thrown, and its StatusCode property == StatusCode.AuthFailed (401), your token's invalid and needs to be regenerated. However, my tokens never expired so far :)

Edt: there is auth, but it's "Bearer" token only, so removed the first sentence to eliminate inaccuracies

[skuill]

@Eimaen thanks for the explanation!
Added some changes to the pull request: #11
Could I ask for a review if you have time and possibility? I will add this changes to the master soon.

[Eimaen]

Sure, glad to help!

[skuill]

@Eimaen thank you so much for a help! Closed, published new library version 1.3.2.