mbuhot

mbuhot

Hi :wave:

I’d like to add a user invitation flow to an application currently using AshAuthentication with the password strategy.

The flow would work something like:

  • An existing Admin user will create the initial User resource
  • AshAuthentication generates a token with ~48h expiry
  • Invitation email is sent to new user including token in a URL
  • User clicks and lands on a page allowing them to set their password
  • Once password set, user is authenticated and redirected to a page in the app

Is this something I can achieve with the password strategy? It’s fairly similar to triggering a password-reset, but has a few differences in the email content, token expiry and UI.

Any suggestions much appreciated, thanks!

Showing Posts 1 to 7

jimsynz

jimsynz

Ash Core Team

I’d suggest looking at the way that the password strategy handles the reset flow - it should be relatively simple to duplicate and modify it to support invites.

My only question is whether this should be a different strategy entirely - ie separate from the password strategy. It seems to me that you may want to invite users to sign up with other strategies also. My gut feeling is that you can use the token resource to store invites (you can store arbitrary data in the extra_data field) that way you can rely on the existing expiration and expunge logic. Perhaps there should also be a setting that disables registration without the invite token?

mbuhot

mbuhot OP

My only question is whether this should be a different strategy entirely - ie separate from the password strategy. It seems to me that you may want to invite users to sign up with other strategies also.

Yes, invitation is more of a registration concern than an authentication strategy.

Perhaps there should also be a setting that disables registration without the invite token?

That would be ideal :+1:
Riffing on the API for resettable something along the lines of:

strategies do
  password :password do
    identity_field :email
    registration_enabled? false  # Disable self-service registration, or perhaps `:invitation_only` here?
    
    invitable do
      accept_invitation_action_name :create_from_invite
      generate_invitation_action_name :generate_invitation
      generate_invitation_accept [
        :email, :first_name, :last_name, :role # params accepted for invitation, stored with invite token
      ]
      token_lifetime 48                        # longer lived token 
      sender fn user_params, token, _opts -> 
        MyApp.InvitationEmail.send(         
          recipients: user_params,
          token: token
        )
      end
    end

    resettable do
      token_lifetime 1                    # shorter lifetime on password reset token
      sender fn user, token, _opts ->     # accepts the full user resource
        MyApp.ResetPasswordEmail.send(
          recipients: user,
          token: token
        )
      end
    end
  end
end
jimsynz

jimsynz

Ash Core Team

What about non-password strategies? ie allowing someone to accept an invite and then sign in with github for example.

mbuhot

mbuhot OP

What about non-password strategies? ie allowing someone to accept an invite and then sign in with github for example.

Could a new top-level Section be added to the DSL?

  invitation do
    accept_invitation_action_name :create_from_invite
    generate_invitation_action_name :generate_invitation
    generate_invitation_accept [
      :email, :first_name, :last_name, :role 
    ]
    token_lifetime 48                        
    sender fn user_params, token, _opts -> 
      MyApp.InvitationEmail.send(         
        recipients: user_params,
        token: token
      )
    end
  end
  
  authentication do
    strategies do
      password do
        # ...
      end

      google do
        # ...
      end
      
      github do
        # ...
      end
    end
  end

Generating and sending an invitation would store a Token record, then when the user lands on the /accept-invitation route, they would be presented with options to ‘Continue with Password’, or ‘Continue with Google’, ‘Continue with Github’, etc based on the available auth strategies.

From the users choice of auth strategy (and possibly some OAuth2/OIDC flow) the corresponding register_with_<strategy> action is called.

jimsynz

jimsynz

Ash Core Team

yeah, I think that would be fairly straightforward to implement as a strategy/add-on.

dan-klasson

dan-klasson

@mbuhot Any progress with this?

mbuhot

mbuhot OP

We ended up using a short-term solution where the password reset flow was adapted to implement an invitation.

Some code details that may be helpful for anyone looking to do the same...

Action on the User resource to generate a token and send invitation:

    update :send_invitation_email do
      require_atomic? false

      change after_action(fn _changeset, user, _ctx ->
               # Generate a password reset token
               {:ok, strategy} = AshAuthentication.Info.strategy(__MODULE__, :password)

               {:ok, token} =
                 AshAuthentication.Strategy.Password.reset_token_for(strategy, user)

               # Send token in Invitation email
               {:ok, email_result} =
                 MyApp.Notifications.UserInvitationEmail.send(
                   recipients: user,
                   token: token
                 )

               {:ok, user}
             end)
    end

Email links to a custom UI presenting a “Set Your Password” message in place of the usual “Reset Password”

I had to work around having multiple password reset routes in the same scope by inlining the reset_route macro:

  scope "/", MyAppWeb do
    pipe_through([:browser, :browser_ash_authentication])

    reset_route(
      live_view: MyAppWeb.PasswordResetLive,
      overrides: [MyAppWeb.AuthOverrides, AshAuthentication.Phoenix.Overrides.Default]
    )

    # Can't have multiple reset_route - inlining macro here to approximate it.
    scope "/accept-invitation", alias: false do
      live_session :accept_invitation,
        session: %{
          "overrides" => [MyAppWeb.AuthOverrides, AshAuthentication.Phoenix.Overrides.Default],
          "otp_app" => nil
        } do
        live("/:token", MyAppWeb.AcceptInviteLive, :accept_invitation, as: :auth)
      end
    end

    ... more routes
  end

The custom UI eventually calls the reset action with:

result =
  MyApp.User
  |> AshAuthentication.Info.strategy!(:password)
  |> AshAuthentication.Strategy.action(:reset, %{
    "reset_token" => token,
    "password" => password,
    "password_confirmation" => password_confirmation
  })
— All posts loaded —

Where Next? Top

Trending in Questions Top

RSP87
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
nseaSeb
Hello, I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
RemyXRenard
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
velrest
So my question is quite simple and i have found no conclusive answer on forum, google or AI. Should we use :erlang.float for Integer to ...
New
samoloth
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New
brecabral
Documentation While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
FlyingNoodle
If a change or preparation module uses Ash.Changeset.get_argument/2 or Ash.Query.get_argument/2 (or any of the other get_argument functio...
New

Other Trending Topics Top

mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews