How to connect on spotify on a headless machine

[eminence]

I'm running spotify-tui on a headless machine, and I'm having some troubles connecting spt to spotify. I did this successfully on an earlier version of spt, but I cannot get it working now.

On my Windows machine (which is the only machine with a browser), created a new app, and I've got access to my client ID and client secret.

When I launch spt on my remote linux machine, I get the instructions about how to create a new app, though I've already done this. So I enter in my Client ID and my Client Secret.

Next, spt opens an elinks browser to https://accounts.spotify.com/login?continue=https://accounts.spotify.com/authorize?scope=... (I've elided the full URL here). The rendered page in elinks is blank, likely because javascript is required to display the login form. When I press q to quit elinks, spt says this in the terminal:

Opened https://accounts.spotify.com/authorize?scope=playlist-read-collaborative%20playlist-read-private%20user-follow-read%20user-library-modify%20user-library-read%20user-modify-playback-state%20user-read-currently-playing%20user-read-playback-state%20user-read-private%20user-read-recently-played&redirect_uri=http:%2F%2Flocalhost:8888%2Fcallback&state=lEklynq5RcRgzKtG&client_id={editedout}&response_type=code& in your browser

Now it just hangs here doing nothing (presumably waiting for my local browser to make the request to the localhost callback.

So now I seem stuck and unsure what to do next.

Thanks for the help!

[Rigellute]

Sorry to hear this! I think I get it.

This sounds like a problem predicted by @jfaltis when implementing auto handling redirect URL https://github.com/Rigellute/spotify-tui/pull/98#issue-331131912.

When you get the redirect URL back in your browser on Windows, it won't connect to the localhost of the remote linux machine. Currently the localhost webserver will wait forever for a response.

To fix this we could

• Set a timeout on the server to fallback to manual url insertion in the console (as suggested by @jfaltis) Or
• Look into not needing to open the browser at all - make the get request for redirect URI from within spotify-tui and parse the response.

The latter solution is more involved but might be best.

Potential workaround

In the meantime, you could try making a manual get request on your remote linux machine. In a separate terminal process try doing something like curl <the url the from the browser>

[eminence]

Ahh, great idea on the workaround. That worked perfectly.

[jfaltis]

@Rigellute I think it's difficult to implement the second solution since we would need to handle the authentication with spotify.com (username, password). Even if we reliably reconstruct the requests for logging in to spotify.com and get it to work it can fail when changes occur on the spotify.com webpage/login process.

[Rigellute]

@jfaltis on reflection you're right. We can't do that!

Instead of the timout, perhaps we could show the manual URL prompt while the server is running? So both methods are valid simultaneously?

[jfaltis]

@Rigellute That would be a nice solution but I don't know if it is possible to cancel io::stdin().read_line from the webserver thread when a GET request is received.

[Rigellute]

Would be nice if we could somehow race the webserver vs read_line 🤔

[hansmbakker]

The proper way for this would be to use the device authorization grant flow - Spotify does this already for its TV applications, but they seem to block other applications from using it. I explained how this works and requested that they enable it in this feature request - please upvote the idea there if you find it useful.

[tobiasfiechter]

Ahh, great idea on the workaround. That worked perfectly.

Does the token expire someday?