Authorization via browser

Question

I am trying to write an app that will interact with Last.fm API and I got stuck. My problem is related to authorization. Quote from Last.fm API site:

Your application needs to open an instance of a web browser and send the user to last.fm/api/auth with your API key and authentication token as parameters. Use an HTTP GET request.

I know how to send GET request and how to open the browser with specified URL. But how can I implement this feature and catch with my app event when user approves or disapproves authorization in browser? Maybe I should use HTTP GET for 15 seconds and if I don't receive username I should ask user to perform authorization again. Is this a right way?

Answer 1

That is somewhat mean. The instructions make it seem simple, but this is actually a difficult problem, and it does not even appear that Last.fm's own liblastfm C++ library for interacting with the service provides a solution.

Some approaches in order of increasing difficulty include:

• Open the default web browser to the URL and display a button for the user to click after he or she has authorized the application.

  Pros: Simple

  Cons: Poor user experience. You will need to make sure that there are clear instructions for the user to follow so that he or she is not confused. Also, a user might think that your app is broken because "they already authorized your app!", not realizing that your app does not know this until he or she presses the button.

• Open the default web browser to the URL, display an indefinite "Waiting for authorization from Last.fm" message, and poll the auth.getSession method API call every 15 seconds or so to see if the user has authorized your application. Perhaps also provide a "Check now" button.

  Pros: Simple and not as poor of a user experience.

  Cons: The API does not appear to provide an error code signaling that the user denied authorization. You might not know if the user ever authorized your app, and you could be waiting forever for authorization. Additionally, I do not know if there are limits on auth.getSession calls, but you may face rate limit issues.

• Embed a web browser in your application. You would have full control over it, and setting up event handlers should be straightforward.

  Pros: No need for polling as the application receives notifications when the user submits a form.

  Cons: The user interface may be confusing to some users.

• Register a custom URI scheme with the operating system and use Last.fm's instructions for authorizing web applications.

  The idea is to register a URI scheme (also called application protocol; e.g. myApp://) and specify a callback URL using the custom scheme (e.g. myApp://lastFmAuthorizationCallback).

  See:

  • Registering an Application to a URI Scheme
  • how do I create my own URL protocol? (e.g. so://…)
  • How to map a custom protocol to an application on the Mac?

• (Platform specific) Automate the web browser. The exact means of doing this depend on the web browser and platform.

  Pros: Can be seamless. Should provide an excellent user experience when done right.

  Cons: Tricky to develop and the automation might break with an upgrade of the browser.

Answer 2

It partially depends on what API you are using to launch the browser process. If you are using an API that you can detect when the launched process exits, use that mechanism. The /auth call to HTTP GET you don't receive any kind of username. According to the rest of the authentication documentation for desktop apps, the browser will close automatically when the user has approved:

Once the user has granted your application permission to use their account, the browser-based process is over and the user is asked to close their browser and return to your application

After this, there are some more steps for you to go through. You next need to call auth.getSession to get a session. If the user hasn't approved your app yet, this call will fail (and you can display a failure to the user that they need to approve your app and give them the link again). Here are the types of possible errors listed:

Errors

4 : Invalid authentication token supplied

14 : This token has not been authorized

15 : This token has expired

4 : Authentication Failed - You do not have permissions to access the service

9 : Invalid session key - Please re-authenticate 10 : Invalid API key - You must be granted a

Etc.

After you have the session approved, then you can start making the appropriate calls