Removing “In progress” state (which was set by voiceinsideyou in 2012) because it doesn’t actually seem to be in progress currently.

It would be possible to implement an endpoint on the AcoustID side that accepts username and the (temporary) access token and returns an AcoustID API key, if the access token is valid. That would be a much better solution than sending the password, which was the original plan. Sending the token to a 3rd party server is still a little sketchy, but much less so than with the password. The only question is whether this should be done automatically (probably when submitting fingerprints for the first time), or we would still require the user to click some button.

Wouldn't https://github.com/musicbrainz/picard/pull/305 help in this matter too ??

Ahh thanks luks, that's heaps better!

Hack is at https://github.com/voiceinsideyou/picard/compare/PICARD-225 - still needs more work though and haven't merged the sslErrors handling yet; realised it was dodgy before so will look at it again

In light of MBH-249, hoping it gets implemented soon, having Picard know how to talk to SSL already would be very nice. Worth noting that MB already uses digest auth for the WS, which at least isn't proven to be insecure – but ideally it'll be possible, after that ticket's implemented, to just do everything over SSL if we feel like it, and I think Picard would be a great place to pave that pathway!

There is a little hack in the acoustid server that allows you to do this more easily. If you submit the parameters to the login page with format=xml or format=json, you will get a xml/json document instead of the web page. This was originally written for jaikoz, but I think it was never really used.

https://github.com/lalinsky/acoustid-server/blob/master/acoustid/website.py#L261

That's awesome that you got it working, even if it's a hack.

On OS X the app bundle automatically links to the system libssl on startup, so there's no problem. Linux distributions should have their Qt libs built with openssl support (or I'd be really surprised if they didn't). I know Arch Linux and Debian do, at least.

I had a play with this and hacked something together last night that works, but I need to talk to luks about it. Scraping the api-key page with a dodgy regex is probably not the greatest idea of something to integrate into Picard, but will see what luks thinks

Another slight problem - the login page requires SSL so I've had to extend XmlWebService to handle https URLs, SslError signals from QT etc. Picard currently doesn't talk to any SSL services and does not handle SSL URLs correctly; nor any SSL handshake errors. It probably has to be sorted at some point in any case for when MB uses a safe login practice for the WS, so may as well extend it now in any case.

Michael - do you happen to know what the situation is with the packages on OSX and Linux - do they typically include/require/depend on OpenSSL libraries etc for use by QT? Seems to be fine for the Windows distribution from what I can tell.