I am trying to implement an auth-flow for AWS Cognito. In doing so, I need to persist some information server side, like an AWS generated session-ID. For example, I enable the user to login, AWS comes back with a challenge for a password reset, I forward the user to a password reset view that contains the session-ID, and then I use that session ID to answer the challenge from AWS.
My question - how do I set session state outside of a plug? Looking at this article (here), I need to setup controllers - however all of my current views are traditional live-views. Is there a way to keep a live-view type architecture and update the connection value?
There is no way around setting up controllers when you need to set session data. This is not a LiveView-specific limitation, it’s that you simply can’t set session data over websockets. The controllers can be very simple, though. You can even just have the POST actions that redirect back to LiveViews eschewing the need for any controller views. You can take a look at how phx_gen_auth does it for more inspiration.
2 Likes
Thanks - I didn’t know if there was a way to jump outside the socket… I guess that is what controllers are for. I see the Phx Auth controller, and I understand the logic of the file, but I don’t understand what points what to the controller.
I see things like this in the live session:
live "/custom_users/reset_password", CustomUserForgotPasswordLive, :new
I see things like this inside the same scope, but outside the live session:
post "/custom_users/log_in", CustomUserSessionController, :create
I guess I need to read up on this.
Look at CustomUserLoginLive and CustomUserSessionController.
You’ll see that the controller on has create and delete actions (both POSTs). The LiveView has a form and instead of a phx-submit attribute, it has an action attribute which causes it to submit like a regular ol’ HTML form. It is POST’d to the controller which then redirects back if the user/pass doesn’t match or calls UserAuth.login_user if it does.
The “session” in live_session is sort of an overloaded term—it only applies to LiveViews allowing you to navigate between them without losing the connection. This is why the controller route is defined outside of it. You still have access to the HTTP session.
