Customize PowInvitation?

I’m working on an application that uses Pow for user authentication. One of the features I need to implement is to invite users, but this is done by a non-interactive process. Users will still verify themselves via the same process. I’m a bit lost in the documentation, but from what I see, I can use PowInvitation.Ecto.Context to create a new user changeset, but the logic of inserting that into the database and sending the invitation would be left for me to implement.

Two questions:

  1. Is this a case where it makes more sense to write the entire Invitation process myself?
  2. If I do write the backend, how do I prevent the Phoenix router from exposing the [:new, :create, :show] routes? My understanding is that these would be automagically exposed via pow_extension_routes()

You can exclude PowInvitation in the Pow.Extension.Phoenix.Router macro opts and add in the routes manually:

defmodule MyAppWeb.Router do
  use MyAppWeb, :router
  use Pow.Phoenix.Router
  use Pow.Extension.Phoenix.Router,
    extensions: [PowResetPassword, PowEmailConfirmation]

  # ...

  scope "/", PowInvitation.Phoenix, as: "pow_invitation" do
    pipe_through [:browser]

    resources "/invitations", InvitationController, only: [:edit, :update]

  scope "/" do
    pipe_through :browser


  # ...

To create the invited user:

PowInvitation.Ecto.Context.create(invited_by, params, config)

To send out the invitation email you need this:

defp deliver_email(conn, user, invited_by) do
  url   = Routes.pow_invitation_path(conn, :edit, [user.invitation_token]]
  email = PowInvitation.Phoenix.Mailer.invitation(conn, user, invited_by, url)

  Pow.Phoenix.Mailer.deliver(conn, email)

PowInvitation expects an invited_by assoc which is the user that initiated the invitation. You can make a custom invite_changeset/3 to ignore it.


That’s exactly what I was looking to do… Thanks @danschultzer!

I guess I’m still stuck on the concept. All the calls for PowInvitation require a Plug.Conn to carry variables through. My use case does not use a Conn, so I feel like I’m trying to reimplement all the methods to get this to work. Am I making this harder than it needs to be?

Update: Maybe I’ve got my solution?

  1. I pull the Pow config from my application’s Config
  2. I create a dummy Conn and use `Pow.Plug.put_config(conn, config) to store
  3. Call the functions as before.

Yeah, this is the easiest. It’s also how you deal with absinthe where you don’t have access to conn:

It’s kinda awkward, but due to how the Phoenix modules all work with conn transformation even if some methods ultimately just fetches the Pow config.

At least I’m not crazy. It still feels a bit wrong, but it does work well, so I guess that’s what matters. Thanks!

One last question:

I’ve customized the user registration template for Pow, but PowInvitaiton wants to use it’s own. I’d like to use the same template for both. I’m still new to Phoenix, so I’m having a hard time figuring out how to have the PowInvitation controller use my custom view/template.

If you’ve set the :web_module in the Pow config, then the extensions will also use custom templates. The PowInvitation templates are generated with mix pow.extension.phoenix.gen.templates --extension PowInvitation, and you should have seen an error if they where not generated visiting the invitation endpoints. The templates will be in templates/pow_invitation.

1 Like

RIght, but it’s a separate template for PowInvitation. I’d rather not duplicate myself with two sets of templates for users to set their passwords. Is it possible for the modules to share the same username/password template?

Set up a partial template in Phoenix, and use that in both:

# pow/registration/new.html.eex

<%= render "_form.html", changeset: @changeset, action: @action %>

# pow_invitation/invitation/new.html.eex

<%= render MyAppWeb.Pow.RegistrationView, "_form.html", changeset: @changeset, action: @action %>

Hey Dan,

I followed your steps to create a custom invite and called PowInvitation.Ecto.Context.create(invited_by, params, config) like you suggested, then passed the user to the deliver_email function like you suggested. But user.invitation_token is the unsigned UUID. So the emails were going out with a link like /invitations/b2a4a605-29e3-41a3-b114-89231db3da0e/edit.

So I modified your deliver_email function you posted like so. Is calling The PowInvitation.Plug.sign_invitation function the best way to generate the signed token for the email. Or is there a higher level function I should be calling to sign the token and generate the user at the same time. Here is my solution below:

defp deliver_invitation_email(conn, user, invited_by) do
    token = PowInvitation.Plug.sign_invitation_token(conn, %{
          invitation_token: user.invitation_token
    url = Routes.pow_invitation_invitation_path(conn, :edit, token)
    email = PowInvitation.Phoenix.Mailer.invitation(conn, user, invited_by, url)

    Pow.Phoenix.Mailer.deliver(conn, email)

I needed to display the invitation link in the app for admin users. This here worked perfectly. Thank you.

1 Like