Replies: 8 comments 1 reply
-
Hi is it possible to share a runnable example so we can take a closer look? |
Beta Was this translation helpful? Give feedback.
-
So this is interesting, ill share my example below, but a little update first. #![feature(lazy_cell)] use axum::{async_trait, debug_handler, error_handling::HandleErrorLayer, Router, routing::get, http::StatusCode, BoxError, response::IntoResponse}; type AuthSession = axum_login::AuthSession; #[derive(Serialize, Deserialize, Debug, Clone)] #[derive(Clone)] #[async_trait]
} #[derive(Debug, Clone, Serialize, PartialEq, Deserialize)] impl AuthUser for User { #[debug_handler] #[tokio::main]
} |
Beta Was this translation helpful? Give feedback.
-
I'm having trouble reading your code blocks and I'm not sure what you mean by "sid" here (the default name for the cookie is "id", so are you using a custom name or something else?) Please provide an example we can run ourselves. |
Beta Was this translation helpful? Give feedback.
-
Sorry, I was unaware the "sid" cookie had been changed to "id" in recent versions, but regardless, it still shows no "id" cookie `#![feature(lazy_cell)] use axum::{async_trait, debug_handler, error_handling::HandleErrorLayer, Router, routing::get, http::StatusCode, BoxError, response::IntoResponse}; type AuthSession = axum_login::AuthSession; #[derive(Serialize, Deserialize, Debug, Clone)] #[derive(Clone)] #[async_trait]
} #[derive(Debug, Clone, Serialize, PartialEq, Deserialize)] impl AuthUser for User { #[debug_handler] #[tokio::main]
}` |
Beta Was this translation helpful? Give feedback.
-
Is it possible that the sessionlayer no longer sets the sid/id cookie anymore? I think in axum_login 0.6 it was dependent on tower-session rather than tower-sessions. They were also decoupled back then. I needed to have every first time visitor receive a session cookie in my last build. It seems this doesnt generate session cookies for clients visiting the site for the first time. It was also possible to integrate the auth and session layers into a larger servicebuilder. Would you recommend I roll back to axum login 0.6 to regain this functionality? |
Beta Was this translation helpful? Give feedback.
-
The session cookie is named "id" by default (but you can configure this to another name if you like). It's important to know that session cookies are not persisted if they're empty. So you need to set some value on the site visitor's session if you want it to persist. |
Beta Was this translation helpful? Give feedback.
-
I really am not following you--why can't you do this? Again we need you to provide a runnable example to help. It's really difficult to help without this. |
Beta Was this translation helpful? Give feedback.
-
Okay! Thats useful information, im sorry but the code i provided runs perfectly fine, its everything below the first sentence, im not sure why it formats incorrectly despite putting it in a code block. If you simple copy and paste it into your IDE you shouldnt have a problem. So basically in this newer version, a client only receives a cookie if its given some type of false data for the session?
I'm not sure why at all, thats the entire reason I raised the issue. I get the "Can't extract auth session. Is AuthManagerLayer enabled?" error on any request when I put the single authmanagerlayerbuilder in any larger servicebuilder stack, if its a standalone servicebuilder i dont get the error. I appreciate the follow-up though! im just going to rollback to a working version and call it good. |
Beta Was this translation helpful? Give feedback.
-
I received this error after enabling setting up my auth layer as so:
let session_layer = SessionManagerLayer::new(MokaStore::new(Some(10_000)))
.with_same_site(::tower_sessions::cookie::SameSite::Strict).with_expiry(Expiry::OnInactivity(time::Duration::minutes(10)));
(within a larger service builder)
.layer(AuthManagerLayerBuilder::new(MySurreal(DB.clone()), session_layer ).build())
Unfortunately I cannot find anything in the documentation that clarifies if I need to explicitly "enable" the middleware after applying it. Is there another middleware that flips the on switch? This error persists regardless of what session store I apply.
In version 6 I was able to successfully implement the necessary traits for SurrealDB to be my backend, I have implemented them this time via wrapper (MySurreal), but I'm unsure if this error could be related. Its rather cryptic.
Beta Was this translation helpful? Give feedback.
All reactions