Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Make confirmation optional? #66
I've limited time right now, but I'll work on an update for this soon
So I tried for the last two weeks to find a solution with configuration, but none was good. I'll look into solving this by forcing developers to write the flow into their apps. The ecto schema modules highlight how I would like the controllers/phoenix to work:
defmodule MyApp.Users.User do use Ecto.Schema use Pow.Ecto.Schema # ... def changeset(user_or_changeset, attrs) do user_or_changeset |> pow_user_id_field_changeset(attrs) |> pow_password_changeset(attrs) end end
This is super easy to read and understand. In contrast to how it would be if it was configuration based:
config :my_app, :pow, user_id_field_changeset: true, current_password_changeset: false password_changeset: true
I think the controllers should work in similar fashion. I haven't found the right way yet, but ideally it would be in the spirit of this:
defmodule MyAppWeb.Pow.RegistrationController do use MyAppWeb, :controller use Pow.Phoenix.RegistrationController plug :custom_email_confirmation when action in [:create] # instead of `plug :pow_email_confirmation` plug :pow_persistent_session # actions already included in the `use Pow.Phoenix.RegistrationController` def custom_email_confirmation(conn, _opts) do # send e-mail and pass thru end end
I'll have to work this idea until I've something that is super straight forward. I don't want to require developers to remember including extensions in several controllers, so there may be a better way of doing all of it in a single module that the controllers can use. The ControllerCallbacks module was a compromise to get extensions to work relatively easy, but I think there is a better way of handling extension support that will be easy to modify.
In the meantime I recommend developers to create custom controllers and modify the flow that way.