Sure, go ahead!
danschultzer
Pow Core Team
Kurisu
So I played a bit with Pow and I can say I am very pleased with its modules and their docs.
Please do you think adding a feature such as disabling users so when the disabled users try to sign in they get a relevant message like “Sorry your account is disabled”. Or maybe this is not a too common feature ?
For now I extendend the users_context module to check if the the authenticating user is disabled and return nil in the authenticate/1 method.
Unfortunately doing that makes both a user entering wrong credentials and a disabled one entering right credentials, get the same error message.
So if I understand well the docs, I will have to create a custom session controller and edit web_app/router.ex. And also provide custom authorization + error handler plugs.
I just want to be sure that this the good way for doing things. But if you’re planing to add such a feature or to make its implementation even easier, it will be of course also fine! 
1
danschultzer
Pow Core Team
You are the second dev to ask for it in two days, so there’s definitely good interest for it. However, I think it’s so trivial that it’s better to let the dev take charge and modify the flow. It helps ensure that developers also adds proper tests to their flow
It’s best to handle it at the plug level. The context module is responsible for interactions with the database, and I prefer that they have very limited logic.
I would add a plug module like this to handle locked accounts:
defmodule MyAppWeb.EnsureUserNotLockedPlug do
@moduledoc """
This plug ensures that a user isn't locked.
## Example
plug MyAppWeb.EnsureUserNotLockedPlug
"""
alias MyAppWeb.Router.Helpers, as: Routes
alias Phoenix.Controller
alias Plug.Conn
alias Pow.Plug
@doc false
@spec init(any()) :: any()
def init(opts), do: opts
@doc false
@spec call(Conn.t(), any()) :: Conn.t()
def call(conn, _opts) do
conn
|> Plug.current_user()
|> locked?()
|> maybe_halt(conn)
end
defp locked?(%{locked_at: locked_at}) when not is_nil(locked_at), do: true
defp locked?(_user), do: false
defp maybe_halt(true, conn) do
conn
|> Plug.clear_authenticated_user()
|> Controller.put_flash(:error, "Sorry, your account is locked.")
|> Controller.redirect(to: Routes.pow_session_path(conn, :new))
end
defp maybe_halt(_any, conn), do: conn
end
And then add the plug to your endpoint OR router depending what works better for your flow:
defmodule MyAppWeb.Endpoint do
# ...
plug Pow.Plug.Session, otp_app: :my_app_web
plug MyAppWeb.EnsureUserNotLockedPlug
# ...
end
defmodule MyAppWeb.Router do
# ...
pipeline :browser do
plug :accepts, ["html"]
plug :fetch_session
plug :fetch_flash
plug :protect_from_forgery
plug :put_secure_browser_headers
plug MyAppWeb.EnsureUserNotLockedPlug
end
# ...
end
I think it would be good to have as a guide, similar to the user role guide: https://github.com/danschultzer/pow/blob/master/guides/USER_ROLES.md
5
OvermindDL1
Isn’t the is_ prefix and the ? postfix redundent? Only one or the other is the pattern (is_ is more common than ? I notice).
0
NobbZ
is_ is usually only used for guard-safe predicates, while ? is used for predicates that can not be used in guards.
1
AstonJ
Might be worth making the changes, copying the entire post - then typing anything in there and clicking save, then edit again and pasting what you actually wanted in there 
Edit: Should be fixed now
1
danschultzer
Pow Core Team
I’ve created a quick PR for a guide on this: https://github.com/danschultzer/pow/blob/locked-users/guides/LOCK_USERS.md
@Kurisu and @dimitarvp (and anybody who’s interested in this) - comments would be super helpful!
4
Kurisu
Great that is fine for me. A Plug is really the right way to go. ^^
My other concern is about the reset_password extension. I think if an user account is locked, sending an email for password reset will be pointless. Any advice about how to prevent such a behavior ? I guess this time we should handle it in a custom reset_password controller.
0
abitdodgy
@danschultzer Would Pow play well with multi-tenancy via Triplex in an Umbrella app? Just putting these terms together is giving me a headache 
I can see that the setup for an Umbrella app is fairly similar except that the Ecto installation is done in a Repo app (assuming your Umbrella app is configured that way). But would setting the tenant dynamically have any impact on Pows config? Any gotchas I should be aware of?
0