Using cached credentials.json for authentication in python-spotipy

[PaulVanSchayck]

Hey there,

Thank you for the excellent work with librespot. Really enjoying it.

I've been trying to build a method to control the playback of librespot on the same headless RPI as where it's running. Mainly to be able to operate it using a infrared remote (through lirc) and GPIO buttons. I've read from other threads the intend is to not build API calls in librespot directly. So the Spotify API seemed like the best alternative. Because my Rust is ahem... rusty, and my Python is better I was considering to use python-spotipy.

I'm connecting to librespot in discovery mode. So I don't have a username/password, but auth_type=1 and auth_data=[string] in the cached credentials.json.

I've been unable to find a method to use those cached credential in the python-spotipy library. It's either missing from there, or I'm not understanding it. Trying to find a workaround, I've hacked my way in the get_token example of librespot to use the cached credentials.

In librespot/examples/get_token.rs:

use std::env;

use librespot::core::config::SessionConfig;
use librespot::core::keymaster;
use librespot::core::session::Session;
use std::str::FromStr;

const SCOPES: &str =
    "streaming,user-read-playback-state,user-modify-playback-state,user-read-currently-playing";

use std::path::PathBuf;

#[tokio::main]
async fn main() {
    let session_config = SessionConfig::default();

    let args: Vec<_> = env::args().collect();
    if args.len() != 3 {
        eprintln!("Usage: {} CREDENTIALS_CACHE CLIENT_ID", args[0]);
        return;
    }
    
    println!("{}", args[1]);
    
    let cache = librespot::core::cache::Cache::new(Some(PathBuf::from_str(&args[1]).unwrap()), None, None, None)
            .expect("Could not create librespot cache");
            
    println!("Connecting..");
    let credentials = cache.credentials().expect("No credentials present");
    let session = Session::connect(session_config, credentials, None)
        .await
        .unwrap();

    println!(
        "Token: {:#?}",
        keymaster::get_token(&session, &args[2], SCOPES)
            .await
            .unwrap()
    );
}

Call with:

cargo run --package librespot --example get_token /path/to/librespot/cache [clientId]

And this works! If I pass a directory with an existing credentials.json (even on my laptop) and the client ID of my Spotify App, I will get back a valid token which I can use in the python-spotipy code again.

So ahem.. this works. And I guess I should/could just build my control calls directly in Rust, based on this example, and not use python-spotipy. But out of interest, what is going on here? Is there a way to use the cached librespot credentials.json directly for authentication in python-spotipy?

Thanks,

Paul

[roderickvd]

Well done upping your Rust game. We can use the help 😉

How are you launching librespot? I just checked with --system-cache cache/ and I end up with filled auth_data in cache/credentials.json.

[PaulVanSchayck]

Sorry, I wasn't clear. I do have a filled auth_data in credentials.json. I've updated my original post to reflect this a bit better.

I'm just wondering what this string represents, as it's not a Spotify API Token. But using my example code, it's enough to request a valid API token. Can I imitate this in spotipy?

[kingosticks]

python-spotipy uses Spotify's Web API, right? Which requires a valid Web API access token to login with.

The auth_data in your librespot cached credentials file is not a Web API access token, it's for another login method which python-spotipy has no idea about. librespot can use the auth_data to login and from there it can get a Web API access token. So no, you cannot use the cached librespot credentials directly with python-spotipy, you need something like your get_token program to bridge the two systems.

EDit: replied to the right message this time

[PaulVanSchayck]

Ok, thanks for clarifying. My suspicion was then mostly correct. Still, I'm wondering. I can even call the (modified) get_token on a different machine with the cached credentials.json. So technically, it should be possible to replicate this call without the librespot code. I've browsed the librespot code, but can't pin point how this is happening. Also tcpdumping the traffic doesn't help, as it's TLS encrypted.

My goal is to reduce the amount of moving parts I need. But if this is not possible, I'll stick to this method. Have to get the cross compile to ARM working, and clean it up a bit. But I guess it will work. I'll post the result here.

In general, I've been surprised how hard it is to create/find something to control playback of librespot (outside the Spotify app itself). I've only found Spotifyd (but doesn't have named pipe output), and vollibrespot (would still need to hack something for their API). Am I missing something?

[kingosticks]

I can even call the (modified) get_token on a different machine with the cached credentials.json. So technically, it should be possible to replicate this call without the librespot code.

I don't understand. Why wouldn't this be possible? Your modified get_token program uses the librespot API to get a token using the auth_data. You can compile this program and run it on any machine. I'm not sure I understand what you mean by "without the librespot code". If you mean without compiling and running the main librespot program, then yes, you don't need that as that is essentially just another example program (albeit a big one) which does something else. However, you do need some way of initially obtaining the auth_data if not using librespot (the program/binary) but you could add this functionality to your get_token program.

You are not missing anything, that doesn't exist. Historically the idea was to keep the librespot main program a more simple proof of concept. Arguably it's gone a bit beyond that lately. I'm also a bit surprised nobody has made something like mpc but for librespot, it'd be a cool project; one day....

[PaulVanSchayck]

Sorry for being a bit dense. I was just trying to make sure I was doing things the Right Way (tm). Thanks for confirming I'm not overlooking anything. The fact you can use the cached librespot authentication (even when using zeroconf) to get a valid Spotify API token for another application is pretty powerful.

I guess Volumio has more or less got the mpc for librespot working. Through their vollibrespot, you can control librespot using their own volumio CLI.

I've got the whole flow working now. It's working pretty nice. I can start playback of playlists from my IR remote control without ever touching the Spotify app. I'll clean it up a bit further, and post it here for reference sake.

[roderickvd]

You could also look at librespot-java. I think that's got an API to control playback.

[PaulVanSchayck]

Took me a while to get back to put everything together, but this solution has been running for a while now. Works nicely.

My modified get_token can be found here. Pass it the path to the directory containing credentials.json and your client ID of your own spotify app. It will give back a valid token for the Spotify Web API.

I've also made a version get_token_args.rs, for convenience, which accepts auth_data and username as argument on the command line.

I had a bit of a challenge cross compiling it. Because my newer Ubuntu 21.10 had a newer glibc version than the RPI. So I created this Dockerfile to create a container for cross compiling.

And finally, I made a small Python wrapper around get_token to also cache the token, for as long as it's valid.

I'm using it for example like this:

#!/usr/bin/env python3
import spotipy
from librespot_token import token

spotify = spotipy.Spotify(auth=token())

state = spotify.current_playback()

if not state or not state['is_playing']:
    spotify.start_playback()
else:
    spotify.pause_playback()

Hopefully this is useful for someone.