GNOME Bugzilla – Bug 647026
Last.fm fingerprinting plugin keeps prompting for login information
Last modified: 2020-03-17 09:27:16 UTC
I've tried authorizing the plugin with Last.fm, and the web page says that it has been authorized, but every time I run it, it asks for the username and password again and again. I already have a last.fm account set up with the song-reporting plug-in, so I would have thought that it could use that. Maybe that part should be a separate bug report? Ubuntu 10.10 32-bit, authorizing with Last.fm from Epiphany (Webkit) 2.30.2
I can confirm this. Banshee was already authorized with my Last.fm account for scrobbling purposes, but Fingerprinting still asked for my login information every time.
Hi, It is because last.fm api use 2 kind of authentication process: 1) for regular webservice 2) for the fingerprint api I use both to get artist, album,... So have to ask login/passwork on last.fm and autorize banshee on website. So you have to fillful both. It will been ask 1 time by session. It is reset if exception is throw during process. The only thing, we can do next to store it is use gnome keyring /similar api on other system...
Any progress on this? I would like to help, if needed.
It is exactly the same need for podcast https://bugzilla.gnome.org/show_bug.cgi?id=492900 Anyway, we need to use standard solution to store password. 2 solutions : - use keystorage.net (external lib to add as dependancy) check licence compatibility... - provide our own access to keyring : >DPAPI on Windows >Keychain Services API on Mac OS X >GNOME-Keyring on Linux gabriel, if you see this what is best according you?
Hrm, KeyStorage.Net looks interesting - already has GNOME keyring support, is MIT/X11 licensed. It's GNOME keyring support does depend on gnome-keyring# though, where I think we should transition to the new FDO secrets DBUS api instead. AFAICT keystorage.net isn't packaged on Linux anywhere either, which is a problem.
(In reply to comment #4) > It is exactly the same need for podcast > https://bugzilla.gnome.org/show_bug.cgi?id=492900 > Anyway, we need to use standard solution to store password. > 2 solutions : > - use keystorage.net (external lib to add as dependancy) check licence > compatibility... > - provide our own access to keyring : > >DPAPI on Windows > >Keychain Services API on Mac OS X > >GNOME-Keyring on Linux > gabriel, if you see this what is best according you? does the patch in #492900 fixes also authentication for lastfm fingerprint ?
no it do not store password in keyring but in db currently...
There is a last.fm command line client that works without password, you can grab it here : svn://svn.audioscrobbler.net/recommendation/MusicID/lastfm_fplib It is released under LGPL so I think you can use it . Perhaps you could use it and wrap into fingerprinting extension, or you can study and eventually copy some code from it or again simply determine how this plugin connects to lastfm.
My first version come from that tool. If you do more than 3 requests, you will be temporary banned. So you have to authorize banshee. The bad news is that it used old auth system and not standard one. We have to send user/pwd with request. The second auth is to get more detail else I only get artist and title (no album). it just need a token from last.fm. So you connect and authorize banshee and that s all.
(In reply to comment #5) > Hrm, KeyStorage.Net looks interesting - already has GNOME keyring support, is > MIT/X11 licensed. It's GNOME keyring support does depend on gnome-keyring# > though, where I think we should transition to the new FDO secrets DBUS api > instead. AFAICT keystorage.net isn't packaged on Linux anywhere either, which > is a problem. regarding this point I think you could create an auth interface that depending on operating system and the environment calls the supported auth method. Doing so the extension doesn't need to know it, it simply pass the auth parameters to the interface. What do you think?
I'm not entirely sure that authentication is required *at all* for fingerprinting. http://www.last.fm/api/show?service=441 track.getFingerprintMetadata <quote> Auth This service does not require authentication. </quote> ...but API key's required (not sure if gnome/banshee has/need it's own unique value, or already has one). If push comes to shove, I'll apply for my own key & load it in a confg file, if required.
As written upper, without auth you can only send 3 requests in before banned for a moment....
I'm not all that clued up on the inner-working, but can only go on what is publicly documented. 2 things stand out: * Although Auth is not required, registration is requestes as a condition for the use of the API, & an API key is provided. As stated before, if a simple mechanism is provided, I'll register for this for my own use & enter the requisite information once-off in a simple config file or dialogue * According to the API spec & ToS: ** https://github.com/lastfm/Fingerprinter <quote> You can freely use fplib in your application without any restriction (see license.txt). Accessing the last.fm API services is restricted to our terms of services (see http://www.last.fm/api/tos). Basically you can do pretty much whatever you want as long as it's not for profit. </quote> ** http://www.last.fm/api/tos - section 4.4 <quote> You will not make more than 5 requests per originating IP address per second, averaged over a 5 minute period, without prior written consent. </quote> This seems to me to be a fairly modest request. Even if the lookups are throttled to 1 fingerprinting lookup per second (to leave requests for other last.fm functions, such as scrobbling, etc), this seems ample to do at least 60 lookups per minute. What am I missing here? Is it just that this particular function is not working as documented? If so, I'd be happy to contact last.fm to see what can be done to smooth over this process.
The TOS is not repespected. I have done a lot of test and still and the bnning system is far more aggressive. I post a comment on the forum on last.fm but never get any response...
@olivier (your message is slightly cryptic, sorry) - please provide a link to the forum post & I can *bump* it to try & get movement on the discussion.
here is the post : http://www.lastfm.fr/group/Last.fm+Web+Services/forum/21604/_/653904
bumped the thread - maybe we can get some movement on that again. is the API returning any error states/code that can be used for debugging the issue form the server/service-side?
I also have this problem. IS there a way around it already?
No - doesn't seem so. I'm guessing we'll need the cooperation of the folks at last.fm, but I've not heard back from them. I suggest that you add your voice to the last.fm forum to try & get attention on this again.
This may be a problem on the client-side. This thread indicated that the API could be working OK with other clients: http://www.last.fm/group/Last.fm+Web+Services/forum/21604/_/751349/1 Has there been any traction on this recently? If this problem persist, could we then please get this specific plugin downgraded from stable/release-worthy to experimental?
(In reply to comment #21) > could we then please get this specific plugin > downgraded from stable/release-worthy to experimental? This plugin is already not part of Banshee Core. It is in BansheeCommunityExtensions repository.
Thanks for the clarification - I see it in the Ubuntu Universe (i.e. community-maintained) repo, not Main.
It can be interesting to check with any packet sniffer (ethreal for example) what is the frame sent for the same file from other client.
good idea. think I'll do a TCP dump or wireshark intercept some time today
as per IRC request, link to last.fm forum post indicating functional API: http://www.last.fm/group/Last.fm+Web+Services/forum/21604/_/751349/1#f15594984
*** Bug 662521 has been marked as a duplicate of this bug. ***
*** Bug 664704 has been marked as a duplicate of this bug. ***
It is still happening with 2.7.0... And seems after authorizing scrobbling brokes till restarting banshee.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.