New Session For Every Request about axum-login HOT 15 CLOSED

Have you tried toggling secure? Note that the examples disable secure because they assume you'll be running locally. By default it's enabled.

from axum-login.

Yes. I tried with_secure on the session layer, but that didn't change what happened. I still got new sessions for every request

from axum-login.

Next try same site.

Getting a new session implies the client is not sending the cookie with the request.

That's likely because of the cookie settings. But you should also inspect the client to see what's happening there.

from axum-login.

SameSite had no effect, but by changing the /login route to POST, I was able to access it using the fetch api in Firefox dev tools. However this didn't work in chrome because of CORS errors. After fixing the CORS errors, chrome ran into the original problem. On Firefox the sessions are reused, and upon inspecting requests, I can see that a cookie header is set on requests from firefox, but chrome doesn't set the session cookie.

Every response to chrome contains a set-cookie header. I'm assuming this is because chrome isn't sending the cookie in the first place. Any ideas why chrome might not send the cookie? SameSite is Strict and secure is true

from axum-login.

You've identified the issue: your client is not sending the cookie.

To fix this you'll have to dig into what cookie settings are necessary to ensure the client sends the cookies.

For dev I would suggest disabling secure and using lax same site.

MDN has good documentation around these topics that might help.

from axum-login.

Alright thanks for your help!

from axum-login.

Not to revive a dead thread that was just resolved, but I am incidentally hitting this precise same issue on Chrome. If you figure out the issue, can you let us know, @BeaconBrigade? At worst, other people can find this thread if the issue is common enough.

from axum-login.

@ejmg please try what I suggested above. These issues relate to how clients (in this case Chrome) will transmit cookies. Cookies need to be configured such that the client will transmit them as expected. The underlying crate for managing sessions exposes an interface for configuring these.

from axum-login.

Turns out, my issue was of the same nature that was discussed in this discussion thread: #45 (reply in thread)

from axum-login.

@ejmg curious in what way? You weren't expecting axum-login to the query the user store?

from axum-login.

I mistook the nature/function of axum_login. I thought that operations like auth.login(&user)... (where auth is some AuthContext<T...> value) also updated the session_store that is passed on to the router.

from axum-login.

@ejmg are you trying to access the the user value in the session directly? I think I'm confused about what you ran into here.

from axum-login.

using the simple-with-roles example as a reference, I mistakenly thought that axum_login automatically updated the users in the user_store that we pass to the AuthLayer struct.

With the setup:

    let session_store = SessionMemoryStore::new();
    let session_layer = SessionLayer::new(session_store, &secret).with_secure(false);

    let store = Arc::new(RwLock::new(HashMap::default())); // [1]
    let user = User::get_rusty_user();

    store.write().await.insert(user.get_id(), user);

    let user_store = AuthMemoryStore::new(&store);
    let auth_layer = AuthLayer::new(user_store, &secret);

and the route:

    async fn login_handler(mut auth: AuthContext) {
        auth.login(&User::get_rusty_user()).await.unwrap(); 
    }

I mistakingly thought that whatever arbitrary user we passed on to auth.login(&some_user).await, axum_login added this user to the original user store [1]. In the case of the example code, the User value returned from get_rusty_user() is already populated in [1] whereas I wasn't doing this with my own project. axum_login was correctly generating the cookie sessions and putting them in my browser and the browser was correctly using them; I simply didn't have any users in my original store, so when I hit a route that was protected, eg:

    async fn protected_handler(Extension(user): Extension<User>) -> impl IntoResponse {
        format!("Logged in as: {}", user.name)
    }

I received a 401 error instead.

from axum-login.

@ejmg ah okay, thanks for the detailed explanation. I think I understand now. The confusion is that axum-login doesn't take an updated user and write it to the store. In other words it doesn't manage the state of the user store in a write fashion only in a read fashion. Is there something we could do in the docs or examples to make that more obvious?

from axum-login.

The misunderstanding is, in my case, definitely one of overall experience and conflating different concepts. At minimum, it might be good to explicitly comment that the user store needs to be pre-populated or, in the case of using the same application DB for users, that you can use the same DB for the user store when configured correctly.

from axum-login.