[GH-ISSUE #410] 400 Only Valid Bearer Authentication Supported #168

New issue

Closed

opened 2026-02-28 14:47:29 +03:00 by kerem · 3 comments

kerem commented

2026-02-28 14:47:29 +03:00

Owner

Originally created by @sputnick1124 on GitHub (Apr 22, 2020).
Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/410

Occasionally (usually after spt has been running for some time), playback will be frozen and any action will result in a "400 Only Valid Bearer Authentication Supported" error from the API.

Wondering if we can handle 400's with a re-auth routine or something similar. If we need better/more granular errors from rspotify, I am working on putting together a PR to address better error descriptions and can work something out there.

Originally created by @sputnick1124 on GitHub (Apr 22, 2020). Original GitHub issue: https://github.com/Rigellute/spotify-tui/issues/410 Occasionally (usually after `spt` has been running for some time), playback will be frozen and any action will result in a "400 Only Valid Bearer Authentication Supported" error from the API. Wondering if we can handle 400's with a re-auth routine or something similar. If we need better/more granular errors from `rspotify`, I am working on putting together a PR to address [better error descriptions](https://github.com/ramsayleung/rspotify/issues/63) and can work something out there.

kerem closed this issue

2026-02-28 14:47:29 +03:00

kerem commented

2026-02-28 14:47:30 +03:00

Author

Owner

@Rigellute commented on GitHub (Apr 22, 2020):

We currently try to perform reauth when the token has expired (here). Perhaps this isn't working properly anymore?

Having more granular errors from rspotify would be great actually, thanks for looking into that!

@Rigellute commented on GitHub (Apr 22, 2020): We currently try to perform reauth when the token has expired ([here](https://github.com/Rigellute/spotify-tui/blob/master/src/main.rs#L303)). Perhaps this isn't working properly anymore? Having more granular errors from `rspotify` would be great actually, thanks for looking into that!

kerem commented

2026-02-28 14:47:30 +03:00

Author

Owner

@TimotheeGerber commented on GitHub (Apr 25, 2020):

I have the same issue. Re-authentication is not working correctly all the time. I checked the code and I think I found the problem.

Re-authentication is done when Instant::now() > app.spotify_token_expiry. These expiration date is computed here, with the current time + token lifetime (expires_in). The problem is that the current time is not the time the token started to be valid when we are using a cached version of the token. As a consequence, it happens that the expiration date is too far in the future to trigger re-authentication.

To solve this problem, the expiration date should be computed from the expires_at field. Unfortunately, it seems there is no from_timestamp function in std::time. I don't want to add another dependency just for that. I will try something and propose a PR if it works.

@TimotheeGerber commented on GitHub (Apr 25, 2020): I have the same issue. Re-authentication is not working correctly all the time. I checked the code and I think I found the problem. Re-authentication is done when `Instant::now() > app.spotify_token_expiry`. These expiration date is computed [here](https://github.com/Rigellute/spotify-tui/blob/4f0c516791be95a85fb29bcf8325eee9672cc86e/src/network.rs#L79), with the current time + token lifetime (`expires_in`). The problem is that the current time is not the time the token started to be valid when we are using a cached version of the token. As a consequence, it happens that the expiration date is too far in the future to trigger re-authentication. To solve this problem, the expiration date should be computed from the `expires_at` field. Unfortunately, it seems there is no `from_timestamp` function in `std::time`. I don't want to add another dependency just for that. I will try something and propose a PR if it works.

kerem commented

2026-02-28 14:47:30 +03:00

Author

Owner

@TimotheeGerber commented on GitHub (Apr 25, 2020):

I found a way to mimic a from_timestamp function in Rust. I put it here in case someone is interested:

use std::time::{Duration, SystemTime};
let time = SystemTime::UNIX_EPOCH + Duration::from_secs(timestamp);

I used this on the expires_at token field to propose the fix for this issue.

@TimotheeGerber commented on GitHub (Apr 25, 2020): I found a way to mimic a `from_timestamp` function in Rust. I put it here in case someone is interested: ```rust use std::time::{Duration, SystemTime}; let time = SystemTime::UNIX_EPOCH + Duration::from_secs(timestamp); ``` I used this on the `expires_at` token field to propose the fix for this issue.

kerem referenced this issue

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

[PR #168] [MERGED] make seeking amount configurable #647