Allow overriding the project id for a given TokenProvider

[MJDSys]

In my company's application, we have created different GCP resources in different GCP projects, to allow us to more easily isolate what applications can access which services. We then wish to have our rust application use a service account with credentials acquired from the metadata service access resources in a different project. Similarly, we'd like the option to have our developers use their local credentials to access different projects for development purposes.

Currently, we are using our own local wrapper to provide this functionality, which looks like this:

pub struct ProviderWrapper<T: TokenProvider + ?Sized> {
    provider: Arc<T>,
    project: String,
}

#[async_trait]
impl<T: TokenProvider + ?Sized> TokenProvider for ProviderWrapper<T> {
    async fn token(&self, scopes: &[&str]) -> Result<Arc<Token>, gcp_auth::Error> {
        self.provider.token(scopes).await
    }
    async fn project_id(&self) -> Result<Arc<str>, gcp_auth::Error> {
        Ok(Arc::from(self.project.clone()))
    }
}

As we found this useful, would a PR implementing this solution on the TokenProvider trait be useful to this project? I'm thinking it would be a new method, override_project(self, project_id: String) -> impl TokenProvider, that would return a similar ProviderWrapper.

Thanks for providing this crate!

[djc]

I'm not sure this fits in well with this crate? I think this crate is about finding ambient authentication context, including tokens and the project which the service is operating in. If you want to operate in the context of another project (but presumably using the same tokens?), I'm not convinced that should be in scope for this crate... Carrying a type like ProviderWrapper in downstream projects doesn't seem like a big deal?

(I would suggest making ProviderWrapper::project an Arc<str> so you don't have to wrap the project in Arc for every call to TokenProvider::project_id().)

(Thanks for the sponsorship, much appreciated!)

[MJDSys]

I'm not sure this fits in well with this crate? I think this crate is about finding ambient authentication context, including tokens and the project which the service is operating in. If you want to operate in the context of another project (but presumably using the same tokens?), I'm not convinced that should be in scope for this crate... Carrying a type like ProviderWrapper in downstream projects doesn't seem like a big deal?

No problem, as you say having that code in our downstream project works for us now. I will point out that other crates are relying on this information (rs-firebase-admin-sdk in our case), so others may find this useful going forward.

But I can understand wanting to keep this crate focused, and if anyone else faces this difficulty they can grab this code. Maybe if many others run into this it may be worth re-examining? If you wish for now, please feel free to close this issue.

(I would suggest making ProviderWrapper::project an Arc<str> so you don't have to wrap the project in Arc for every call to TokenProvider::project_id().)

True, I can see about updating our code/the example above once I've tested it.

[djc]

Happy to keep this issue open and reconsider if more people come forward that would find this useful.