[GH-ISSUE #370] Database storage for access token #116

Closed
opened 2026-02-27 20:23:13 +03:00 by kerem · 2 comments
Owner

Originally created by @v3lmx on GitHub (Dec 4, 2022).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/370

Hello!

Is your feature request related to a problem? Please describe.
I want to store the access token obtained in the Authorization Code Flow with request_token() in a database, to handle multiple users.

Describe the solution you'd like
Either :

  • (easier solution I would think) : have a method to directly get the token, such as this one (issue 96) previously implemented (not is the codebase anymore as far as I can tell)
  • (nice to have but probably not the scope of this project) : store the token in database directly the spotify object is configured with a toggle for Database

Describe alternatives you've considered
I tried implementing a new Trait for AuthCodeSpotify to rewrite the function request_token, but quickly encountered private enums and functions (such as params), so it felt like rewriting the whole crate for a single function.

Additional context
The method currently used to get the token is request_token, and it "stores the token internally" in cache if it is configured, and nowhere if it is not as far as I can tell.
I'm pretty new to rust so I may have missed something.

I would be willing to give a try to this issue if you think it is a desired feature, if you can give me some pointers to put me in the right direction :)

Originally created by @v3lmx on GitHub (Dec 4, 2022). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/370 Hello! **Is your feature request related to a problem? Please describe.** I want to store the access token obtained in the Authorization Code Flow with `request_token()` in a database, to handle multiple users. **Describe the solution you'd like** Either : - (easier solution I would think) : have a method to directly get the token, such as [this one (issue 96)](https://github.com/ramsayleung/rspotify/issues/96) previously implemented (not is the codebase anymore as far as I can tell) - (nice to have but probably not the scope of this project) : store the token in database directly the `spotify` object is configured with a toggle for Database **Describe alternatives you've considered** I tried implementing a new Trait for `AuthCodeSpotify` to rewrite the function `request_token`, but quickly encountered private enums and functions (such as `params`), so it felt like rewriting the whole crate for a single function. **Additional context** The method currently used to get the token is `request_token`, and it *"stores the token internally"* in cache if it is configured, and nowhere if it is not as far as I can tell. I'm pretty new to rust so I may have missed something. I would be willing to give a try to this issue if you think it is a desired feature, if you can give me some pointers to put me in the right direction :)
kerem 2026-02-27 20:23:13 +03:00
Author
Owner

@ramsayleung commented on GitHub (Dec 9, 2022):

have a method to directly get the token, such as https://github.com/ramsayleung/rspotify/issues/96 previously implemented (not is the codebase anymore as far as I can tell)

I think the get_token method in BaseClient could satisfy your need, you could disable the cache and get token from client:

github.com/ramsayleung/rspotify@2fe5035531/src/clients/base.rs (L36)

fn get_token(&self) -> Arc<Mutex<Option<Token>>>;

Then You could get data from Token and save them into database as you want.

<!-- gh-comment-id:1344426522 --> @ramsayleung commented on GitHub (Dec 9, 2022): > have a method to directly get the token, such as https://github.com/ramsayleung/rspotify/issues/96 previously implemented (not is the codebase anymore as far as I can tell) I think the `get_token` method in `BaseClient` could satisfy your need, you could disable the cache and get token from client: https://github.com/ramsayleung/rspotify/blob/2fe50355312d90d9b93d3731ecdc1dda3c569a03/src/clients/base.rs#L36 ```rust fn get_token(&self) -> Arc<Mutex<Option<Token>>>; ``` Then You could get data from `Token` and save them into database as you want.
Author
Owner

@v3lmx commented on GitHub (Dec 9, 2022):

Got it ! It works :)
This method doesn't fetch the token so I didn't think to use it in combination with request_token() that actually goes to spotify to get it.

In case anyone encounters this problem, solution snippet below :

// Callback function called by spotify
#[get("/callback?<code>")]
async fn callback(jar: &CookieJar<'_>, code: String) -> AppResponse<BasicResponse> {
    let mut spotify = init_spotify(jar);

    // Fetch the token
    let _res = spotify.request_token(&code).await;

    // Get it to store it in databse
    let token_mutex = spotify.get_token();
    let mut token = token_mutex.lock().await.unwrap();
    let mut token: &mut Token = token.as_mut().expect("Token can't be empty as this point");

    info!("Token: {}", token.access_token);
    // ...
<!-- gh-comment-id:1344594791 --> @v3lmx commented on GitHub (Dec 9, 2022): Got it ! It works :) This method doesn't fetch the token so I didn't think to use it in combination with `request_token()` that actually goes to spotify to get it. In case anyone encounters this problem, solution snippet below : ```rust // Callback function called by spotify #[get("/callback?<code>")] async fn callback(jar: &CookieJar<'_>, code: String) -> AppResponse<BasicResponse> { let mut spotify = init_spotify(jar); // Fetch the token let _res = spotify.request_token(&code).await; // Get it to store it in databse let token_mutex = spotify.get_token(); let mut token = token_mutex.lock().await.unwrap(); let mut token: &mut Token = token.as_mut().expect("Token can't be empty as this point"); info!("Token: {}", token.access_token); // ... ```
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/rspotify#116
No description provided.