How do I use guard transparency with references?

[buehler]

Hey Sergio and all other important people of this framework

It is really amazing what you did!
To contribute, I'm trying to create an authentication guard for ZITADEL, such that users can use the guard directly and don't need to fiddle around with OAuth Introspection themselves.

I'm quite done with the code and the docs. However, something bothers me before I want to release the new version of the crate:

In the documentation of rocket (0.5-rc), I found the documentation about the guards and their examples. In the section about Guard Transparency, they talk about increased security when leveraging request guard transparency for all data access.
The example uses a reference to a guard.

However, when constructing the object during the FromRequest method, how am I able to return a reference and therefore "inject" the reference to the guard in a method? As far as I know, it is not possible to return a reference to an object that runs out of scope afterwards (rightfully so).

My guard code can be found here: https://github.com/smartive/zitadel-rust/blob/feat/rocket-auth/src/rocket/introspection/guard.rs

I really struggle on how I'm able to return a reference to my created struct instead of the normal type (it does not implement copy however.).

Currently it is:

#[async_trait]
impl<'request> FromRequest<'request> for IntrospectedUser {

instead of:

#[async_trait]
impl<'request> FromRequest<'request> for &'request IntrospectedUser {

Can somebody nudge me in the right direction?

Thank you all, and a happy new year!
Regards

[buehler]

Ok so, after another try, I found out that I'm able to return a reference if I use the local_cache (or local_cache_async).

Is it correct to use this cache to create the request-bound object and return a reference to it?
If any other guards are created that need to construct some instance, do they actually need to use the cache?

In my case, using the cache makes sense such that the introspection call is not repeated for the same request, but other use-cases may vary.

[SergioBenitez]

You are able to return references safely! This is what lifetimes are for. You simply need to let the type system know where the reference comes from. You do this using a lifetime annotation:

fn f<'r>(v: &'r T) -> &'r T
{ v }

Applied to request guards, your guard would need to hold a reference to the request. This implies that the guard's type must have a lifetime generic. Then simply concretize the generic as the lifetime of the request in the impl and Rust should take care of the rest.

[buehler]

Thank you for the quick answer!
I kind of fixed it with local_cache_async since it is better to cache the introspection result for the whole request.

But using your explanation, would this be correct? :

pub struct User<'r>{
  test: &'r str;
}

#[async_trait]
impl<'r> FromRequest<'r> for &'r User<'r> {
  type Error = ()

  async fn from_request(request: &'r Request<'_>) -> Outcome<Self, Self::Error> {
    &User { "hello" }
  }
}

[buehler]

Then again, I "need" a ref (or PhantomData) in the user. (if I understand correctly)

[SergioBenitez]

It doesn't really matter where the lifetime comes from or where it goes exactly, all that matters is that the guard type is constrained by the lifetime. This is what ensures that Rust can prevent the value from existing beyond the lifetime of the request, which is a particularly unique property to Rust.

To constrain by said lifetime, you have a few options:

• Hold a borrow to the request in the struct. That is, literally have a field of type &Request in the structure somewhere.
• Use PhantomData to carry the lifetime in the type only without actually taking the borrow for a ride.
• Use request local storage to store the value in the request itself so that the value itself is borrowed from the request, and so it trivially cannot outlive it.

All of these are valid mechanisms. I would likely opt for them in the order I presented above, preferring from top to bottom. But as I said, they are all valid.

[the10thWiz]

Hold a borrow to the request in the struct. That is, literally have a field of type &Request in the structure somewhere.

I've found this to be problematic, since the Request type has a generic lifetime parameter, and my understanding is that the lifetime parameter is not tied to the 'r request lifetime. In the past, I've found just holding a reference to part of the request (i.e. the URL, or anything else) to work better. (Although in those cases, I actually needed those specific parts of the request for potential method calls).

[buehler]

Right, it does make sense. In my case, using the local cache (https://github.com/smartive/zitadel-rust/blob/main/src/rocket/introspection/guard.rs#L77-L110) was sufficient since I don't want to repeat the introspection call anyway. However, good idea if I implement some other guards.