How to modify an existing reqwest client to add an Authorization header with a bearer token?

[busf4ctor]

Problem explanation

I am developing a Rust library that interacts with a web service requiring authentication. The library accepts a reqwest::Client instance from the user during initialization, performs a login request to an endpoint, and needs to use the bearer token received from the login response for subsequent requests.

The challenge arises because reqwest::Client instances are immutable after creation, which aligns well with the builder pattern and ensures thread safety. However, this immutability poses a problem when trying to add an Authorization header to the existing client, as the bearer token is only available after the login request.

Here's a simplified version of the code:

use reqwest::{Client, Error};
use serde::{Deserialize, Serialize};

#[derive(Serialize)]
struct Credentials {
    username: String,
    password: String,
}

#[derive(Deserialize)]
struct LoginResponse {
    token: String,
}

async fn login_and_set_token(client: &Client, credentials: Credentials) -> Result<(), Error> {
    let login_url = "http://example.com/login";
    let res = client.post(login_url)
                    .json(&credentials)
                    .send()
                    .await?
                    .json::<LoginResponse>()
                    .await?;
    
    let token = res.token;
    
    // How to proceed here to add the token to the client's Authorization header?
    
    Ok(())
}

This code is part of a library, meaning the user passes their own reqwest::Client during struct creation. Creating a new client with the Authorization header, as I've seen suggested in some approaches, could potentially lose any custom configuration the user has applied to the client they passed in. This could include, but is not limited to, proxy settings, custom headers, timeouts, etc.

Possible solution

I've considered asking the user to provide a function that takes a reqwest::ClientBuilder and returns it, allowing them to apply their custom configurations. This function could then be used whenever I need to create a new client instance, ensuring that the user's configurations are preserved, including the necessary Authorization header for authenticated requests. However, I'm uncertain about this approach and its implications on the usability and design of the library.

fn user_customization_function(builder: reqwest::ClientBuilder) -> reqwest::ClientBuilder {
    // User applies custom configurations to the builder
    // For example, setting a proxy:
    builder.proxy(reqwest::Proxy::all("http://myproxy:8080").unwrap())
}

// In the library, we use the provided function to apply the user's configurations
// and then add the Authorization header:
fn create_client_with_token(customize_builder: fn(reqwest::ClientBuilder) -> reqwest::ClientBuilder, token: &str) -> Result<reqwest::Client, Error> {
    let builder = reqwest::Client::builder();
    let customized_builder = customize_builder(builder);
    let client_with_token = customized_builder
        .default_headers({
            let mut headers = header::HeaderMap::new();
            headers.insert(header::AUTHORIZATION, header::HeaderValue::from_str(&format!("Bearer {}", token)).unwrap());
            headers
        })
        .build()?;
    
    Ok(client_with_token)
}

Question

What is the best way to modify the existing client to add a new Authorization header for subsequent requests without losing the original client's configuration?

Is there a recommended pattern or practice in Rust for this scenario, especially considering the library context where flexibility and preserving the user's client configuration is important?

[seanmonstar]

The client is purposefully meant to be immutable once built. This is to prevent surprising behavior of modifying the configuration while other requests using the client are being scheduled or in-flight.

You could make it so you expose some ApiClient that adds such a header to every request. Better integration with middleware could likely help in the future, but doesn't work yet (it's on the roadmap for this year).