starred/spotify-tui

Fork 0

mirror of https://github.com/Rigellute/spotify-tui.git synced 2026-04-26 08:05:57 +03:00

[GH-ISSUE #136] How to connect on spotify on a headless machine #75

New issue

Open

opened 2026-02-28 14:46:48 +03:00 by kerem · 8 comments

kerem commented

2026-02-28 14:46:48 +03:00

Owner

Originally created by @eminence on GitHub (Nov 5, 2019).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/136

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!

Originally created by @eminence on GitHub (Nov 5, 2019). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/136 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 <kbd>q</kbd> 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!

kerem commented

2026-02-28 14:46:49 +03:00

Author

Owner

@Rigellute commented on GitHub (Nov 5, 2019):

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>

@Rigellute commented on GitHub (Nov 5, 2019): 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>`

kerem commented

2026-02-28 14:46:49 +03:00

Author

Owner

@eminence commented on GitHub (Nov 5, 2019):

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

@eminence commented on GitHub (Nov 5, 2019): Ahh, great idea on the workaround. That worked perfectly.

kerem commented

2026-02-28 14:46:49 +03:00

Author

Owner

@jfaltis commented on GitHub (Nov 6, 2019):

@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.

@jfaltis commented on GitHub (Nov 6, 2019): @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.

kerem commented

2026-02-28 14:46:49 +03:00

Author

Owner

@Rigellute commented on GitHub (Nov 6, 2019):

@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?

@Rigellute commented on GitHub (Nov 6, 2019): @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?

kerem commented

2026-02-28 14:46:49 +03:00

Author

Owner

@jfaltis commented on GitHub (Nov 7, 2019):

@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.

@jfaltis commented on GitHub (Nov 7, 2019): @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.

kerem commented

2026-02-28 14:46:49 +03:00

Author

Owner

@Rigellute commented on GitHub (Nov 7, 2019):

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

@Rigellute commented on GitHub (Nov 7, 2019): Would be nice if we could somehow `race` the webserver vs `read_line` 🤔

kerem commented

2026-02-28 14:46:49 +03:00

Author

Owner

@hansmbakker commented on GitHub (Jan 9, 2023):

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.

@hansmbakker commented on GitHub (Jan 9, 2023): 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](https://community.spotify.com/t5/Spotify-for-Developers/Device-Authorization-Grant-authentication-flow-for-custom/m-p/5485468) - please upvote the idea there if you find it useful.

kerem commented

2026-02-28 14:46:50 +03:00

Author

Owner

@tobiasfiechter commented on GitHub (Jul 11, 2023):

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

Does the token expire someday?

@tobiasfiechter commented on GitHub (Jul 11, 2023): > Ahh, great idea on the workaround. That worked perfectly. Does the token expire someday?