New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make confirmation optional? #66

Open
kidbombay opened this Issue Jan 12, 2019 · 3 comments

Comments

Projects
None yet
2 participants
@kidbombay
Copy link

kidbombay commented Jan 12, 2019

Can we add a feature so you still get to use the confirmation flow (sends email) but confirmation is not required to proceed after registration?

@danschultzer

This comment has been minimized.

Copy link
Owner

danschultzer commented Jan 13, 2019

I've limited time right now, but I'll work on an update for this soon 😄 The flow exists in the controller callback. The most obvious fix is to just add a :pow_email_confirmation_allow_sign_in configuration option for Pow, but I'm not sure if it's the best way to handle configurations for the extensions. I'll give it some thought and return to this asap!

@kidbombay

This comment has been minimized.

Copy link
Author

kidbombay commented Jan 13, 2019

Thank you!

@danschultzer

This comment has been minimized.

Copy link
Owner

danschultzer commented Jan 27, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment