abstract bay
I spent a bit of time looking at the SessionAuth object today. It requires that we have a SessionMiddleware in play, and it needs that to sit before it in the middleware stack.
The way it handles this is to insert a MiddlewareWrapper instance into the middleware stack, and on first call it constructs a new stack of middleware that wraps SessionAuthMiddleware in ExceptionHandlerMiddleware, and then wraps that in SessionMiddleware.
SessionAuth.session_backend_config accepts an instance of either CookieBackendConfig or ServerSideSessionConfig and uses this to create the new SessionMiddleware instance that I mentioned above.
What happens if a user has already added the session middleware to the application as documented, and then also adds the session auth? Then there are two session middleware in the stack, right? Is this an issue?
So, it seems like if using SessionAuth we shouldn't add SessionMiddleware directly, rather let SessionAuth do it.
However, what happens in the case where another plugin should have SessionMiddleware available also, such is the case with litestar#3420. In that case, we are iterating over the middleware stack, looking for a SessionMiddleware so that we can raise an ImproperlyConfiguredException if one isn't found. Due to the way that SessionAuth works, if a user has added SessionAuth to their application, and they add the FlashPlugin, they'll get the exception about SessionMiddleware not being available, even though it is.
I think we should do the same with SessionAuth as we are implementing for FlashPlugin, that is, have it check for SessionMiddleware during init, but raise an error if it is not found, and instruct the user to add it explicitly. That way, the state of the middleware stack is in plain view. We can then explicitly sit SessionAuthMiddleware immediately after SessionMiddleware in the stack.
Thoughts?
hollow crown