mbuhot
Hi ![]()
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!
Trending in Questions
I having some trouble figuring out if I have set myself too strict of standards for my production server. Currently I can handle 75% of r...
New
Documentation
While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
Hello,
I’m trying to build a basic Phoenix web-app, and I’d like to use Tailwind.
However, when I launch mix phx.server, I get an error...
New
Hi everyone,
I am toying with the idea of building a “match maker” for giving personal help to people that wants to start coding.
I sta...
New
I recently noticed that Elixir’s Logger defaults its primary log level to :debug when no :logger, :level application configuration is pre...
New
I’m working on a small exercise involving update_in/3, and I came up with this solution:
data = %{
name: "Periodic Table",
category:...
New
I’ve got trouble wrapping my head around the order in which functions are called in this snippet (from Phoenix’s authentication):
toke...
New
Other Trending Topics
Edit: 2026 May 15 - This post is archived.
Mob is alive!!
Main docs: mob v0.7.11 — Documentation
A bit of explanation for the slightly c...
New
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hobbes is a low-level distributed database for the Elixir programming language.
Hobbes provides a simple, safe, and scalable storage lay...
New
A little off-topic, but I feel like people here have a good head on their shoulders.
I used to be quite good at making software. Was luc...
New
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex










Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
jimsynz
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_datafield) 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
Yes, invitation is more of a registration concern than an authentication strategy.
That would be ideal
Riffing on the API for
resettablesomething along the lines of:jimsynz
What about non-password strategies? ie allowing someone to accept an invite and then sign in with github for example.
mbuhot
Could a new top-level Section be added to the DSL?
Generating and sending an invitation would store a Token record, then when the user lands on the
/accept-invitationroute, 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
yeah, I think that would be fairly straightforward to implement as a strategy/add-on.
dan-klasson
@mbuhot Any progress with this?
mbuhot
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:
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_routemacro:The custom UI eventually calls the
resetaction with: