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 https://github.com/heartcombo/devise or https://github.com/volatiletech/authboss.

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(),
        )))
    }
})
2 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.