current
The current invite system creates a new account and provides a recovery link.
This creates a lot of accounts on accident. How ever has access to the link also has access to the account for a short time.
goal
Use registration flow/api for invites. But guard it with an registration token. Which is invalidated after one use.
tasks
design
- checking invites
- proxy for POST /self-service/registration (this is the endpoint responsible for registering the account)
- the proxy checks if the invite is valid
- the proxy invalidates the invite if the registration was successful
- invites
- invites could be stored in keto, my app already uses keto and than there is no extra db requirement
- invites should be persisted
- invites should be linked to created and user
current
The current invite system creates a new account and provides a recovery link.
This creates a lot of accounts on accident. How ever has access to the link also has access to the account for a short time.
goal
Use registration flow/api for invites. But guard it with an registration token. Which is invalidated after one use.
tasks
design