Strange `actix_identity::Identity` behavour when used with `configure`. about actix-extras HOT 3 CLOSED

Did a bit more playing around and found that if you were to declare your key outside of the closure passed to HttpServer::new(/* ... */) it works as expected. Maybe some issue with the lifetime of the key reference? Here is the code that I used to allow this to work:

    // ...

    let key = rand::thread_rng().gen::<[u8; 32]>();

    HttpServer::new(move || {
        App::new()
            .wrap(IdentityService::new(
                CookieIdentityPolicy::new(&key)
                    .name("test")
                    .max_age(60000)
                    .secure(false),
            ))
            // register handlers ...
    })
    // ...

Edit
Was thinking about it, and it makes sense. The closure passed to HttpServer to create the App is called by each worker, which Actix spins up 8 by default. So each worker would have a different key because the random function call happens within the closure. By moving it outside the closure and calling clone you ensure each worker gets the exact same value for the key.

@robjtede I don't believe this is a bug, just the way Actix works.

from actix-extras.

Replaced actix_identity by actix_session. Now I'm able to login on /login and see user1 at /cfg/index and vice versa. Either something is wrong with actix_identity (because when I see Anonymous cookie doesn't go anywhere, it's still there), or I don't understand how it works.

I didn't mention it above but if you login using actix_identity, you'll see Anonymous user on / after minute or so, even so cookie's age is set to be huge. It doesn't happen now with actix_session. I send request to / and still see user1

from actix-extras.

I believe it has something to do with how you are generating the key for the CookieIdentityPolicy.

First thing I did was change the code to match what is in the actix-identity documentation which resolved the issue:

CookieIdentityPolicy::new(&[0; 32])
    .name("test")
    .max_age(60000)
    .secure(false)

Second thing I did was try using a hard coded random key, which also resolved the issue:

CookieIdentityPolicy::new(
    "SomE LoNg RanDOm K3y That Ha5 Lett3Rs AnD NUm83Rs".as_bytes()
)
.name("test")
.max_age(60000)
.secure(false)

NOTE: The second approach is how I've typically done this in the past, I'll have an environment variable set that I will load into the app and use:

CookieIdentityPolicy::new(
    std::env::var("APP_KEY")
        .expect("APP_KEY not set.")
        .as_bytes()
)
.name("test")
.max_age(60000)
.secure(false)

If you want this to be generated randomly at runtime rather than being set as an environment variable, then you can check out this section of the Rust Cook Book on crating random keys from alphanumeric characters.

from actix-extras.