Thank you so much! It is easy and explicit for us to pull out a separate context for this separate set of users so no problem, was just curious. Thanks Dan!
rrosztoczy
danschultzer
Pow Core Team
Announcements
Sponsorship
For the last year I’ve been working full time on open source using my own funds. It’s been a great experience, so now I’m experimenting with GitHub Sponsors to see how this could work longer term. If you use Pow for your business and would like to show support, here’s the link: https://github.com/sponsors/danschultzer
Pow Business
I’m working on a MVP for an identity provider built on Pow: https://powauth.com/business/.
It’ll target smaller startups and developers. I would love to hear from you if you are interested in this solution.
Pow 1.0.16 and 1.0.17 released
Changelog: Github
Hex: pow | Hex
These were two meaty releases that mostly has a lot of under-the-hood improvements.
Prevent user enumeration
Pow now protects against user enumeration attacks when PowEmailConfirmation extension is enabled. As an example, this means that instead of an error message being shown if an e-mail is already taken, the user will see a message that informs them to check their inbox to confirm the e-mail the same way as if the registration succeeded.
Improved documentation
Added security practices guide, and updated the production checklist with an e-mail rate limitation section.
Thanks for all the contributions and feedback 
12
hwatkins
Dan,
Thanks for developing Pow and Pow Ascent, it’s great to have such a good framework for authentication in Elixir.
I had a question on unlinking from auth provider like Google, what is the expected result? It redirects to the change password page, I was expecting it to leave the user record and ask to set a password, but maybe I misunderstood the flow.
danschultzer
Pow Core Team
Thanks! It’ll always redirect to the registration edit page, either with an :error or :info flash: pow_assent/lib/pow_assent/phoenix/controllers/authorization_controller.ex at v0.4.5 · pow-auth/pow_assent · GitHub
Deletion will always fail if no password is set and there’s only one identity for the user.
knowthen
ryloric
Hi!,
I’m trying to integrate Pow with an API following the API guide docs. I was wondering if there’s a way to stop Pow.Plug.create_user ( which is used from a RegistrationController ) from creating a new session if the user creation is successful. I want to just send a confirmation email and redirect to my login page client-side instead.
I can’t find any callback within Pow.Plug.Base which lets me do that.
- I can create the user, but not return the struct back to Pow from
APIAuthPlug(custom plug to replacePow.Plug.Session), which won’t create a session for the user automatically. - Another option is to write a custom function, but then I’d be out of Pow’s flow of things and it might get too complicated.
I think both options are bad. I tried to trace the code flow through Pow and it seems like Pow.Plug.create_users calls into Pow.Plug.create/3, which in turn ends up at APIAuthPlug.create.
How should I go about this? Any help is appreciated!
Thanks!
Edit:
I can just copy Pow.Plug.create_user function in my RegistrationController and do something like this..
defmodule RegistrationController do
def create(conn, %{ "user" => params}) do
conn
|> custom_create(params)
|> case do
{:ok, user, conn} ->
send_confirmation_email()
json(conn, %{message: "Please check your email"}
{:error, changeset, conn} -> ....
end
end
# Copied from Pow.Plug.create_user/2
def custom_create(conn, params) do
alias Pow.Plug
config = Plug.fetch_config(conn)
params
|> Pow.Operations.create(config)
end
end
It feels hacky, but it should work.
danschultzer
Pow Core Team
While you can use Pow.Operations.create/2, it makes more sense to just call the context module:
defmodule MyAppWeb.API.V1.RegistrationController do
use MyAppWeb, :controller
alias Ecto.Changeset
alias Plug.Conn
alias MyAppWeb.ErrorHelpers
@spec create(Conn.t(), map()) :: Conn.t()
def create(conn, %{"user" => user_params}) do
user_params
|> Pow.Ecto.Context.create(repo: MyApp.Repo, user: MyApp.Users.User)
|> case do
{:ok, _user} ->
send_confirmation_email()
json(conn, %{message: "Please check your email"}
{:error, changeset} ->
errors = Changeset.traverse_errors(changeset, &ErrorHelpers.translate_error/1)
conn
|> put_status(500)
|> json(%{error: %{status: 500, message: "Couldn't create user", errors: errors}})
end
end
# ...
end
For your use case this would probably be the best. But in the PowEmailConfirmation extension I just delete the session in the controller callback with Pow.Plug.delete/1.
ryloric
Thanks for replying!
This makes much more sense, why reach into plug when what I really want is the context.
ryloric
Hi!,
One more question, the API guide says to use PowPersistentSession.Store.PersistentSessionCache in APIAuthPlug to keep the renew_token, but it doesn’t seem to be working anymore? Also, that stuff’s no longer in the docs for 1.0.18.
Should I writing a custom plug using PowPersistentSession.Plug.Base? I don’t think it’s possible to use the Cookie plug for an API.
ryloric
Couldn’t edit the previous post.
I ran mix deps.clean and mix deps.get and that seems to have fixed PersistentSessioCache problem. Earlier keys weren’t being persisted, but they’re being persisted correctly now. Not sure what that problem was.