Actix authentication using middleware or guard?

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

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

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.

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?

@Lesso, any news on this?

It would be amazing to have in Rust community something like or

What do you think about?

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

Maybe this can help you A Auth By Session Middleware

1 Like

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;
    } else {
        log::warn!("no id: {:#?}", &req);
                .header(http::header::LOCATION, "/login.html")

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.

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.

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 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.