Pow Controllers and LiveView

Hello Everyone,
I’m trying to make Pow register form validation trough LiveView which I more or less succeeded at. However, upon user creation pow normally would log the user trough the plug:
from pow docs

 def create(conn, %{"user" => user_params}) do
    conn
    |> Pow.Plug.create_user(user_params)
    |> case do
      {:ok, user, conn} ->
        conn
        |> put_flash(:info, "Welcome!")
        |> redirect(to: Routes.page_path(conn, :index))
       ...
   end

My LiveView event currently looks like this (i had to create a custom function create_user in order to escape the conn needed for the Plug but now Im trying to figure out how to log in the user on creation…

def handle_event("save", %{"user" => user_params}, socket) do
    case Accounts.create_user(user_params) do
      {:ok, _user} ->
        # Form is valid
        {:stop,
         socket
         |> put_flash(:info, "user created")  
         |> redirect(to: Routes.live_path(socket, MyApp.SearchLive))}
..

So basically is there a way to pass the conn trough my liveview or i shall copy/write the entire functionality myself.

@danschultzer somewhere in the forum you’ve mentioned that you would put a demo with liveview did you ever get around to do that ?

Thanks for your time

Why do you want this in a LiveView?

Very good question, this was a task given to me by a “mentor”. Initially I got that as to validate the form on the fly and I believe most of the app would move into liveview and the form would expand.

PS. looking into your profile its the first time i get to know about fullstackphoenix. Thank you for your time keeping this up

Thanks.

I can’t say for sure its a bad idea to have a live validation on the registration (or login) form but it seems overly complicated and could be a security risk. Especially if you check for if email is already used. I just can’t see the upside other than learning how it works behind the scenes.

1 Like

I don’t want to ruin your learning experience but take a look at the https://github.com/danschultzer/pow/blob/master/lib/pow/phoenix/controllers/registration_controller.ex

I would also go through this issue https://github.com/danschultzer/pow/issues/271

The last thing you want to figure out is the differences between session and token based authentications and how to handle session based authentication in a LiveView socket.

1 Like

You can’t set cookies in a WebSocket. You have to pass the session id value to the client and set up some custom JS client side that will set it as a cookie. There’s some security issues too. I would recommend that you only deal with auth in HTTP.

Haven’t gotten to it yet. I’m trying out a Pow implementation with Phoenix.Socket though, hopefully can take what I learn from that and add it to the Pow docs/code :slight_smile:

2 Likes

Thank you everyone!

This is one of the usecases I have highlighted all along for where LV shines. Imagine a registration form where you necessarily want to improve UX because it directly increases conversions. You want to give the user feedback as soon as possible when they are trying to sign up, so realtime validations are essential, but LV allows you to add it without bringing int a client side solution and all the baggage that comes with it. The outstanding issues with a full LiveView signin or registration form is the cookie session writing on login or sign up. This can’t happen over websockts so folks have two options.

  • Use phx-change on the form, but allow the regular form post to hit a controller that performs put_session
  • Use LV for phx-change and phx-submit, and perform a redirect to a session controller, with a signed token which is used to call put_session to write the session

So LV is can be used here without any of the mentioned security issues. You are of course free to use regular controllers if that’s a better fit :slight_smile:

12 Likes

What I was thinking was just use the validation and post it to the pow custom controller. Thank you Chris. And exactly one of the reasons to use LV on such a simple task is the added “user value”.

Now that LV approaches v1 thanks to all the work you put in. I think it will be great to put some beginner friendly documentation. I hope I will get to the level being able to contribute back.

1 Like

You want to give the user feedback as soon as possible when they are trying to sign up, so realtime validations are essential

You mean something like that? :slight_smile:

Sure, I know how LV validations works. I was just imagine a more simple use case where you add email and password, since Pow was mentioned. And for that use case, I think LV is overkill.

I didn’t like the example. Or at least its too aggressive out of the box. Its that configurable?

Right, but the original post asked specifically about registration so I wanted to highlight specifically how LV is a great fit here. At the end of the day, the LOC vs LOC is going to be about the same for a controller vs LV, so don’t be too quick to dismiss as overkill, especially since the poster is already using LiveView. Would I bring in LiveView if my only feature was a sign in page and I wasn’t using it anywhere else? No, but most folks are using it well beyond this single case so there is more nuance here.

In essence, I agree with you and I should have answered the actual question. But also, as senior developers, we need to tell people that just because you have a shiny new hammer, not everything is a nail. But yes, the UX and code quality is WAY better so thank you (for my shiny new hammer)

You can define own validators similarly as we did. The output of validator has to be Result.t().

Thanks!