Several basic questions on design and operation

[ericaltendorf]

I have a bunch of questions which probably would be obvious to someone with more experience with session management, but I'm a noob, and I didn't see the answers in the docs, so ... here I am ... will appreciate any help!

The AuthManagerLayer is intended to be used across all routes which might want or set auth session information, but does no access control itself, right? You need to either use the supplied macros or write your own checks, correct?

The AuthManagerLayer uses a SessionManagerLayer internally to manage the cookie, yes? Is that session layer only for use by the auth layer, or can it be used separately? If separately, should it be added to the router? Also, the AuthManagerLayer has a pointer to a Backend, which likely overlaps with backend resources that might be passed around in an AppState extension. Overall, how should responsibilities be assigned to the auth, session, and state layers/states added to the router?

Is AuthnBackend::get_user() called for every request? I'm trying to figure out why one of my handlers is failing to find a User in its auth context, and noticed that get_user() isn't called on those requests, which seems weird. If it's not called on every request, how is it supposed to be used? If it is supposed to be called on every request, what might cause it to fail to be called?

Relatedly, isn't the User stored in the session MemoryStore? In that case, we shouldn't need to call get_user() on each request, but then, what is get_user() for; why couldn't authenticate() do the work get_user() does and stash the output in the session store?

[maxcountryman]

Happy to help, thanks for reaching out.

The AuthManagerLayer is intended to be used across all routes which might want or set auth session information, but does no access control itself, right?

Correct.

You need to either use the supplied macros or write your own checks, correct?

That's right. The macros are hopefully helpful defaults, but for complete control, you're able to implement your own access control middleware which would leverage AuthSession.

Is that session layer only for use by the auth layer, or can it be used separately?

It can be used elsewhere too and in fact once you've installed the auth layer, you can use Session directly in your handlers. One thing to point out here is that it's probably not a good idea to install tower-sessions multiple times: what this means is you probably want to install the auth service at the lowest common point in your routes.

Overall, how should responsibilities be assigned to the auth, session, and state layers/states added to the router?

This is a good question and I'd like to try to spend some time putting together better examples around this to help demonstrate some of the patterns we think will work best.

Is AuthnBackend::get_user() called for every request?

Correct. This is encapsulated by AuthSession::from_session.

I'm trying to figure out why one of my handlers is failing to find a User in its auth context, and noticed that get_user() isn't called on those requests, which seems weird. If it's not called on every request, how is it supposed to be used? If it is supposed to be called on every request, what might cause it to fail to be called?

This sounds like something isn't working as intended--do you have an example you can share?

Relatedly, isn't the User stored in the session MemoryStore?

Not the user, but the user ID.

why couldn't authenticate() do the work get_user() does and stash the output in the session store?

It's not impossible but it puts more constraints on the generics. This design is heavily influenced by Django's auth middleware, so the API is meant to be quite similar to that.

[ericaltendorf]

Thank you, very helpful.

Given what you said, the possibility that get_user() is not being called is more likely a bug in my code or instrumentation. I'll keep an eye out for it and I can reproduce it with code I actually trust I'll let you know.

I did run into another potential issue. I'm also following along this example, largely for the error handling patterns. I'm having some issues propagating errors how I'd like to (ie use a consistent error type throughout the app which can be processed by a response mapper middleware).

I think what's going on is that my AuthnBackend::authenticate() and get_user() return a Result over my own error type crate::error::Error, which is also what I set AuthnBackend::Error to. Now, in my handlers, I call auth_session.authenticate(), but the problem is that returns a Result over Error<Backend>. But my handler returns crate::error::Error, so if I try to propagate the error as is, the compiler seems to be sure it's not type compatible:

mismatched types axum_login::session::Error<Backend> and error::Error have similar names, but are actually distinct types

Not sure if this is a design concern or I just don't know how to hint the compiler to equate the types...?

[maxcountryman]

I'm having some issues propagating errors how I'd like to

If it's possible to share your code, I might be able to give you better pointers.

At a high level, one thing you can do is define an error enum and then map specific errors to a particular variant of that enum. Just bear in mind that you'll either define this as part of your app-level error type or need to provide some mapping between the app error type and this error type.

[ericaltendorf]

The code base is not in a good sharing state :-/ ... but, let's see what we can do. First, I realized that yesterday I was confusing AuthnBackend::Error with axum_login::session::Error<Backend>. The former is what I set to my custom error enum, and is what I'm returning from authenticate(), but yeah I can't find any code that would equate it with the latter.

So let me rephrase: How can I return a custom error (say, AuthnBackend::Error::UsernameNotFoundInDB) from authenticate(), then pass it upwards through a login handler, where I might have code like:

    let user = match auth_session.authenticate(creds.clone()).await {
        Ok(Some(user)) => user,
        Ok(None) => return Err(Error::AuthFailNoUserReturned),
        Err(error) => return Err(error),
    }

Right now this code won't compile because Error::AuthFailNoUserReturned is of type AuthnBackend::Error, but error is axum_login::session::Error<Backend>.

I'd like the error passed upwards where it will be caught in a response mapper middleware that will write a log message and map the error to something to return to the user.

If this is still not enough context I'll try to get something shareable or a minimal repro.

[maxcountryman]

Right now this code won't compile because Error::AuthFailNoUserReturned is of type AuthnBackend::Error, but error is axum_login::session::Error.

Note that the authenticate method is wrapping the error defined by your specific backend (that's what Backend::Error is here).

If you have another error type that's able to be converted into a response then you could map_err in your handler to that type, for example.

This is a little vague, sorry about that--the examples try to illustrate this. If you do end up with code you can share I'm happy to help with that too.

[arcstur]

Why it's not a good idea to install tower-sessions multiple times? If for example I want to save some custom configuration in the user's session, to use in AuthSession I would have to modify the User struct, but with tower-sessions I can just insert it directly. Is that correct? What would be the best approach?

[maxcountryman]

axum-login already installs tower-sessions for you. Why would you want to install the session middleware a second time?

[arcstur]

oh so by installing axum-login I can use the session directly without using AuthSession? That's nice!

[maxcountryman]

Yes. Its associated Service type is CookieManager<SessionManager<AuthManager<...>, ...>>.