Is there a more idiomatic way to implement authentication?

[limo520]

There are several solutions in my mind at first glance.

First, using request guard in every route handler.

I have the requirements of changing permission dynamically, so it seems not applicable to my case.

Second, using request guard in on_request callback of the fairing.

I can't do that as the guide docs state "on_request may not, however, abort or respond directly to the request".

Finally, using a special route which matches all request and is used to authenticate and forward.

I implement the third as below:

struct Auth;
#[async_trait]
impl<'r> FromRequest<'r> for Auth {
    type Error = String;
    async fn from_request(request: &'r Request<'_>) -> Outcome<Self, Self::Error> {
        let paths = vec!["/authed"]; //May get from backend
        info!("{:?}", paths);
        let path = request.uri().path().as_str();
        if paths.contains(&path) {
            info!("{} need auth", path);
            let outcome = request.guard::<CurrentUser>().await;
            return match outcome {
                Outcome::Success(_) | Outcome::Forward(_) => Outcome::Forward(Status::NotFound),
                Outcome::Error((_, error)) => Outcome::Error((Status::Unauthorized, error)),
            };
        }
        info!("{} don't need auth", path);
        Outcome::Forward(Status::NotFound)
    }
}
#[get("/<_..>", rank = 0)]
fn auth_get(_auth: Auth) {}

#[get("/authed", rank = 1)]
fn authed() -> &'static str {
    "authed"
}
#[get("/unauth", rank = 1)]
fn unauth() -> &'static str {
    "unauthed"
}

Although it seems to work, but there are still some difficulties.

1. I have to specify rank for every route attribute, because I can only assign positive numbers to rank which has lower priority than the default rank.
2. Each requst method should have it's own route function, maybe this can be done with macros.

So, is there a more idiomatic way to implement this?

[SergioBenitez]

First, using request guard in every route handler.

I have the requirements of changing permission dynamically, so it seems not applicable to my case.

What does this mean? What is your case, and why wouldn't a guard based approach work?

[limo520]

For example, an api requires authentication now, but after a while, it is going to permit all without login.

[SergioBenitez]

For example, an api requires authentication now, but after a while, it is going to permit all without login.

If you'll need to change the API at that point, then you'd remove the guard. Or if it's some change that happens in some state, then the guard can check that state.

[limo520]

Thanks,I understand.
BTW, what about the third? Is this an appropriate usage of route? In my view, it acts as filters or interceptors in other framework. By doing that，I can wholly ignore authentication in route functions. Also, that's why I considered on_request as a solution at first.

[SergioBenitez]

It's fine, it sort of works, but in my opinion it's more work than "doing the right thing". If you forget to set the ranks correctly, things will appear to work but actually be insecure; it doesn't let you implement the idea of Guard Transparency, which prevents that from being possible.