Actix authentication using middleware or guard?

help
1

What is the best approach to implement http authentication (validation) using actix web?

Using the provided examples for a simple-auth-server I can authenticate a request and create a cookie accordingly.

Now I want to validate the cookie/identity in order to prevent access from certain routes. A Guard doesn't cut it because I can only retrieve the stored identity using Identity::from_request(HttpRequest, Payload) and in RequestHead (guard implementation), there is neither the full request nor its payload.

I can not use Middleware either because I will only get access to ServiceRequest but not HttpRequest.

1 Like
2

I'm using the openid protocol with an external authentication provider (keycloak) and just copied the example from the openid crate that uses actix-web.

1 Like
3

Thanks for your input.
They are actually just using the FromRequest trait on the User struct to do authorization.
That's an idea I guess.
This helps, but I'm still curious if this is the best approach.
For now I can do it like this though.

4

I'm still looking for a good solution to this problem.
Maybe somebody can have a look into this.

I'm using CookieIdentityPolicy to achieve cookie-based session management. I built some sort of authentication on top of it and I now want to implement a Guard to do some path based checks. For that, I would like to retrieve the Identity. So far I came up with this in order to retrieve the authentication cookie value, but since the CookieIdentityPolicy handles the decryption of the value, I didn't get any further. Can anybody hint me in the right direction or share some best practice?

5

@Lesso, any news on this?

It would be amazing to have in Rust community something like GitHub - heartcombo/devise: Flexible authentication solution for Rails with Warden. or GitHub - volatiletech/authboss: The boss of http auth..

What do you think about?

6

Sadly not. I have even been asking for help in the Actix Gitter channel several times without success.

7

Maybe this can help you A Auth By Session Middleware

1 Like
8

One can also use a wrap_fn to protect a given scope to authorized users. When the user does not have an identity cookie, this does a redirect.

.wrap_fn(|req, srv| {
    if req.get_identity().is_some() {
        use actix_service::Service;
        srv.call(req)
    } else {
        log::warn!("no id: {:#?}", &req);
        Either::Right(ok(dev::ServiceResponse::new(
            req.into_parts().0,
            HttpResponse::Found()
                .header(http::header::LOCATION, "/login.html")
                .finish(),
        )))
    }
})
3 Likes
9

This looks very promising but when I do this and click the back button on localhost after a call to 'forget' in the logout handler the user still seems to be authenticated in requests to the API made from the cached page.

10

Check whether the browser still has a cookie set after invoking the logout. If so, that's the issue.

Identity::forget() should remove the cookie. It sounds like that is not happening.

11

Thank you - I did that and the cookie vanished in dev tools and then was resurrected after pressing the back button. I don't fully know what is happening but I think it may have something to do with browsers differentiating localhost and 127.0.0.1 for some purposes and identifying them for others relating to cookie management. In any event I will leave off pursuing it on this thread as I am satisfied that it doesn't really relate to the original question or your very helpful answer.

12

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.