Porting from FastApi (Python) to Poem Rust - Feedback required

[chikko80]

Hi guys,

i want to try to port my application from fastapi (python) to poem.
I really love the way how fastapi is designed and poem_openapi looks very similar.

I am relatively new to rust, so don't blame me if that's a dumb question.

I really liked the dependency injection system of fastapi, as you could just depend on some kind of custom middleware and if the user provides the right bearer token, the user object gets directly injected into the route.
I tried to replicate that in rust with the extractor pattern mentioned in the examples.
Is that the right way how I am doing this? Should I use a different approach?

My problem is that I don't know how to integrate that as a security schema so that it works with the swagger ui.
My goal is to have a login endpoint where the user can get a jwt token and on all the other routes i want to have the user object injected into the route via the jwt token that the user provides.

Is there a way to add kind of new types to the as security scheme? Not sure about the current architecture...

I am very thankful for any feedback about this!

pub struct UserApi;

struct User {
    name: String,
}

#[OpenApi(tag = "OpenApiTags::AuthApi")]
impl UserApi {
    /// Get Current User
    #[oai(path = "/", method = "get")]
    async fn get_user(&self, current_user: User) -> Result<PlainText<String>> {
        Ok(PlainText(format!("Hi user: {}", current_user.name)))
    }
}

#[poem::async_trait]
impl<'a> poem::FromRequest<'a> for User {
    async fn from_request(req: &'a Request, body: &mut RequestBody) -> Result<Self> {
        // TODO
        // extract bearer token from request
        // if valid return user
        // if not return 401
        Ok(User {
            name: "Peter".to_string(),
        })
    }
}

[sunli829]

This is the first way, a custom Extractor is used to extract the username from Bearer.

fn parse_user_from_token(token: &str) -> Option<String> {
    todo!()
}

#[poem::async_trait]
impl<'a> poem::FromRequest<'a> for User {
    async fn from_request(req: &'a Request, body: &mut RequestBody) -> Result<Self> {
        use poem::web::headers::authorization::Bearer;
        use poem::web::headers::Authorization;

        let username = req
            .headers()
            .typed_get::<Authorization<Bearer>>()
            .and_then(|bearer| parse_user_from_token(bearer.0.token()))
            .ok_or_else(|| Error::from_status(StatusCode::UNAUTHORIZED))?;

        Ok(User { name: username })
    }
}

But I prefer to define a security scheme so it can be shown in swagger.

struct User {
    name: String,
}

#[derive(SecurityScheme)]
#[oai(type = "bearer", checker = "parse_token")]
struct MyUserAuthorization(User);

async fn parse_token(req: &Request, bearer: poem_openapi::auth::Bearer) -> Option<User> {
    todo!()
}

#[OpenApi]
impl UserApi {
    /// Get Current User
    #[oai(path = "/", method = "get")]
    async fn get_user(&self, user: MyUserAuthorization) -> Result<PlainText<String>> {
        Ok(PlainText(format!("Hi user: {}", user.0.name)))
    }
}

[chikko80]

Got it! Thanks, I didn't realize I can reuse the bearer token security schema for my use case.

[NexRX]

@sunli829 Sorry to bump an older discussion but when parsing in the checker ...checker = "parse_token"....
What is the best way to return an (error) message as to why the check may fail?

I'm currently checking a token expiry, authority, permissions all at once. So without being able to say why the check failed in the response, it ends up lacking some context that could help in some cases.

Do you recommend an alternate way or can I attach some context to the request and catch it later perhaps?

[sunli829]

@sunli829 Sorry to bump an older discussion but when parsing in the checker ...checker = "parse_token".... What is the best way to return an (error) message as to why the check may fail?

I'm currently checking a token expiry, authority, permissions all at once. So without being able to say why the check failed in the response, it ends up lacking some context that could help in some cases.

Do you recommend an alternate way or can I attach some context to the request and catch it later perhaps?

Not yet, maybe in the next version I will let the checker function return the Result type.

[NexRX]

I wouldn't mind contributing a PR if your happy to defer and if it sounds good for a first contribute?

[chikko80]

I'd also love to have a Result returned👍🏻 we'd then have a consistent error handling on all edges

[sunli829]

I wouldn't mind contributing a PR if your happy to defer and if it sounds good for a first contribute?

Welcome to PR😄

[NexRX]

#625 :D