flmel
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
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
andreaseriksson
Why do you want this in a LiveView?
flmel
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
andreaseriksson
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.
Schultzer
I don’t want to ruin your learning experience but take a look at the pow/lib/pow/phoenix/controllers/registration_controller.ex at main · pow-auth/pow · GitHub
I would also go through this issue Instructions for WebSocket usage (e.g. Phoenix Channels and LiveView) · Issue #271 · pow-auth/pow · GitHub
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.
danschultzer
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
flmel
Thank you everyone!
chrismccord
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.
put_sessionput_sessionto write the sessionSo 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
flmel
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.
ondrej-tucek
You mean something like that?
andreaseriksson
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.