Juggling with URLs

When the user launches the script in Listing 2, it outputs

Server available at http://localhost:8082

to inform the user about the web address they need to enter in their browser's address box. Then, the browser displays a link labeled Login on Spotify. If you press this, the browser redirects you to the Spotify site and prompts you to log in with your username and password.

If the user acquiesces to the terms (Figure 6), Spotify sends the browser back to the local test server – in Listing  2, this is localhost:8082 – and issues a valid access and refresh token. With the latter, OAuth::Cmdline later manages to renew expired access tokens. The script (Listing 2) saves the access credentials in the .spotify.yml file in the user's home directory.

Figure 6: The user confirms that the PerlSnapshot application is allowed to read their private playlist data until further notice.

In other words, if the user presses Okay, the Spotify server branches back to the registered Redirect URI. The test server in OAuth::Cmdline::Mojo sets this to http://localhost:8082/callback. Make sure you entered this in exactly the same way when filling out the application on the Spotify developer site; otherwise, things will go wrong.

Caution: After you add a redirect URL, as shown in Figure 5, Spotify strangely requires you to click the Save button at the bottom of the page. If you forget this, you will wonder later why you are seeing Bad Request or Invalid Redirect URI server error pages.

Access Until Further Notice

Not only can the current Unix user read the data in the newly created local credentials file, but also a curious system administrator (or a successful intruder) with root privileges – so be careful. Using this detour, the user has now granted the server permission to hand over user data to the PerlSnapshot application, until explicitly revoked; the app authenticates with a valid access token in the HTTP header for each request.

Recycling

Other scripts, like the one in Listing 3, can now call the constructor of OAuth::Cmdline with the site parameter set to "spotify" and extract a valid access token from the ~/.spotify.yml cache file.

To read a user's playlists, in line 16 I use the authorization_headers method from OAuth::Cmdline to send the access token required by the server in the subsequent GET request to the web API. Should the access token have expired in the meantime, OAuth::Cmdline automatically renews it behind the scenes. To accomplish this, the module uses the refresh token, which is also stored in the cache file, to send a request to the handler for the OAuth refresh service on the server.

The answer returned in JSON format contains the names of all the user's playlists and their hex IDs; later on, scripts such as Listing 4 retrieve the music referenced there. Thanks to OAuth::Cmdline, you no longer need to do battle with OAuth but can focus on the data to be read.

After picking up the data of one of the previously obtained playlist IDs in Listing 3 (hardcoded in line 23 of Listing 4), the songs-in-playlist script stores them in YAML format, which is easily readable by both humans and machines (Figure 7).

Figure 7: The playlist data has now been save to a YAML file as a local backup copy.

This puts worried and concerned music lovers in the happy position of being able to back up their playlists on a regular basis. In this way, all of the effort they put into their music collection is preserved  – even if they would like to give a cold shoulder to their previous rental music provider  – or vice versa.