Optional headers in functions about zitadel-rust HOT 6 CLOSED

If I understand correctly, then this would mean that if I make two calls in succession from an AdminServiceClient which need different x-zitadel-orgid headers, then I would need to create two separate clients where one has the additional interceptor and one doesn't.

With the current workaround you can reuse the same client and only add the extra header to each call.

We could also wrap the current workaround in a trait. Something like this:

pub trait WithZitadelHeaders<T>: tonic::IntoRequest<T> {
    fn with_orgid(self, id: String) -> Result<tonic::Request<T>> {
        let mut request = self.into_request();
        request.metada_mut().insert("x-zitadel-orgid", id.try_into()?);
        request
    }
}

impl<T> WithZitadelHeaders<T> for tonic::IntoRequest<T> {}

It should then be possible to do:

let request = AddUserGrantRequest { ... }.with_orgid("foo".to_string())?;
client.add_user_grant(request)?;

from zitadel-rust.

This seems like the better idea to be frank.

from zitadel-rust.

I've found a workaround (I guess it's the recommended way of doing this):

let request = AddUserGrantRequest { ... };
let mut request = request.into_request();
request.metadata_mut().insert("x-zitadel-orgid", my_org_as_header_val);
client.add_user_grant(request).await

from zitadel-rust.

Hey @aDogCalledSpot

Good call.

Theoretically, we could extend the current way the "chained interceptor" works and let users add specialized interceptors for such use cases.

from zitadel-rust.

What do you imagine this would look like?

I'm not too unhappy with the workaround so unless the proposed solution is substantially more ergonomic it might not be worth the effort compared to simply documenting this workaround.

from zitadel-rust.

I agree with you.

Right now, you have the option to use the ClientBuilder and then add the chained methods "with access token" or "with service account".

When you build a client, the registered auth method decides which interceptors are attached to the grpc client. The chainedinterceptor is required because of the return type of the client builder. As such, we can always expect a AdminServiceClient<InterceptedService<Channel, ChainedInterceptor> (or other client, but the "InterceptedService..." is the key part).

Now, in theory, we could allow a with_interceptor and/or add_interceptor method in the builder that receives a list of interceptors. When building the clients, we could add these interceptors to the clients. The return type should still be the same, but we have the possibility to add multiple intercpetors to the clients.

That way, you could create an interceptor that simply adds the forementioned header to all calls.

from zitadel-rust.