Can the confirmation email be manually re-sent in ash_authentication?

There definitely isn’t a built in UI for this, so something custom would need to be added on your end. With that said, are you storing all tokens using the store_all_tokens? config? If so you can lookup the old token and send it, something like:

Token
|> Ash.Query.filter(subject == ^"user_#{^user.id}" and purpose == "confirm" and expires_at < now())
|> Ash.read_one()
|> case do
  ... # call your sender with the user and the token
end

If you aren’t storing tokens, then you’d do something like

claims = %{"act" => "confirm"}
strategy = AshAuthentication.Info.strategy(User, :confirmation)

{:ok, token, _claims} = Jwt.token_for_user(user, claims, token_lifetime: strategy.token_lifetime)

# call your sender with the user and the token

This definitely isn’t as ergonomic as it could be, but adding resend with a nice interface (likely via an update action on the user, like resend_confirmation, would likely take some time, so I’m looking to provide ways you can achieve this in the short term. If you could open an issue requesting first-class support for this that would be great

Thanks for the quick response @zachdaniel, I’ll give this a try.

I’m finally digging into Ash and +1’ing this as a not-yet-but-probably-will-be user

I dug into this a bit this morning. I am storing the tokens. I think this will work as long as the token hasn’t yet expired. If the token has expired, I think I would still need a way to programmatically generate a new token. Is there a way to do this?

I suppose I could also extend the expiration on the token but that doesn’t seem ideal from a security perspective.

Generating a new token is definitely doable There re actions on the token resource to generate new ones, so you can create a new confirm token at any point.

To see the actions available on the token resource:

Ash.Resource.Info.actions(YourApp.Accounts.Tokens)

Hey @zachdaniel …

Wondering if there has been any official work on this feature since the OP.

I just went through upgrading to require email verification (before access) and in the course of it, ran into the same problem.

Here’s the solution I came up with. If it’s in any way sketch I’d appreciate the feedback (or a pointer to a more official implementation)!

First off, in my router.ex I just added a post action to handle a “send verification again” link:

    post "/resend-confirmation", PageController, :resend_confirmation

Then, implemented the following function on my PageController:

  alias AshAuthentication.AddOn.Confirmation
  alias WasteWalk.Accounts.User
  alias User.Senders.SendNewUserConfirmationEmail

  def resend_confirmation(conn, _params) do
    user = conn.assigns[:current_user]

    cond do
      is_nil(user) ->
        conn |> put_flash(:error, "You must be signed in to resend a verification email.") |> redirect(to: ~p"/sign-in")

      user.confirmed_at != nil ->
        conn |> put_flash(:info, "Your email is already verified.") |> redirect(to: ~p"/")

      true ->
        strategy = AshAuthentication.Info.strategy!(User, :confirm_new_user)
        changeset = Ash.Changeset.new(user)
        {:ok, token} = Confirmation.confirmation_token(strategy, changeset, user)
        SendNewUserConfirmationEmail.send(user, token, [])
        conn |> put_flash(:info, "Verification email sent. Please check your inbox.") |> redirect(to: ~p"/")
    end
  end

And… it seems to work fine.

The bit about is_nil(user) being redirected to sign in is, I think, a solid security approach. Basically, the workflow ends up being:

1. First time user signs up, lands on home page, we send verification email. User is technically authenticated (we know the user token) but, they aren’t verified yet (user.confirmed == nil). In my app, they can see the home page but have no further access. (I show a “check your email to verify your account” message on the home page if they aren’t confirmed yet).
2. User doesn’t see email. Clicks “send it again” and we do. User is stuck here until they actually get the email and verify.
3. If the user token expires, etc., then when they return they won’t be authenticated. They’ll have to go back to the login page, and only option at this point is either a) do a password reset or b) use a magic link (which I also support).

So, bottom line… if they wait a long time and their token expires, there’s no way to get a new validation link other than password reset or magic link. Which I think is fine for me.

Alternatively, I could add an option to enter an email and get a new validation link but I don’t see the need for it.