How long does the email template changePasswordId id last before it expires? How can invitation expiration be implemented?

[stephen]

Hello,

For future users that land on this topic, I've figured out an answer for the first question—"How long does the email template changePasswordId id last before it expires?". The Account Created email has a variable in it called changePasswordId in it that you can use it to the reset the users password by passing it to the Change a User’s Password API. The expiration time setting for this changePasswordId is called Setup Password in the FusionAuth settings. There is a different expiration time setting for the changePasswordId that is returned from the Start Forgot Password Workflow. That changePasswordId setting is called Change Password. Both of these expiration time settings can be adjusted in the FusionAuth UI by navigating to the advanced settings of the tenant.

I've ran into some issues with the invitation flow and providing a good experience to the users of our application. One issue I'm having is that is that there is no way to distinguish an error for the invite user flow from an error on a reset password flow. This means that I can't display "Your invite has expired" to the user, I can only give them a generic, your invite didn't work message with no direction for recourse other than telling them that they can reset their password to get their account back. This is not a desirable behavior for our application. Please let me know if there are any solutions to this that I'm missing.

The workflow I would like to achieve in our application UI is the following:

• Invites expire after 7 days
• In the list of users I can see what users have accepted the invite and which haven't
• If user's invite has expired, an admin can resend them the invite

There doesn't seem to be the concept of invites expiring in FusionAuth (Email Verification can expire, but that doesn't prevent change password requests). What I'm thinking I would need to do to achieve this is the following:

• Set Email Verification in the advanced tenant settings to 7 days (604800 seconds)
• Store a boolean for if the password has been initially set—this will let us know if the invite has been accepted. We can call this hasInviteBeenAccepted.
• Intercept the complete reset password API
  • If 7 days have not passed, reset the password and set hasInviteBeenAccepted to true
  • If 7 days have passed and hasInviteBeenAccepted is false, return an error
• If 7 days have passed
  • Remove application registration to deny login attempts
  • If hasInviteBeenAccepted is false, display a button on the users screen for admins that allow them to resend the invite. The user will also need to be reregistered to the application.
    • I think the only way to resend the initial invite is to remove the user and recreate them
• Intercept the initiate password reset request
  • If hasInviteBeenAccepted is false, return an error
  • If hasInviteBeenAccepted is true, initiate the password reset request

Am I missing anything? Are there any suggestions for a better workflow for this?

Is this something that makes sense to be included as a feature of FusionAuth?

Thanks,
Stephen

[dan]

So what I'd do is control access to the application outside of the normal FusionAuth flow.

Set up a page in your application to send people an invite. Only admin users can do so. (This solves the re-sending problem as well.)

When an invite is sent, record the timestamp and the fact that the user was invited on the user object (in the data field. Create the user, but don't register them to the fusionauth application.

When the user tries to register, it depends if you are building your own registration page or not. Given your custom needs, I'd recommend building it. In that case, you'd just see if they existed and were able to be authenticated (using the login api). After the login api returns (it'll be a 202, since they are authenticated but not authorized for the application), check to see if the timestamp is within 7 days. If so, they're registered and fine. If not, then they are presented with an error message.

As far as being able to query, if you are using elasticsearch, anything in user.data can be queried, so you could show all the users with an invited flag and a invitedTimestamp of less than 7 days. I don't have any examples of this elastic search query, but here's an example of how to run this against a registration.data field: https://fusionauth.io/docs/v1/tech/guides/advanced-registration-forms#searching-on-user-data

Does that make sense?

An alternative is to file a feature request, but I agree, the setupPassword functionality isn't quite like an invitation feature.

[stephen]

This is great, thanks Dan.

I have one question though regarding resends:

Set up a page in your application to send people an invite. Only admin users can do so. (This solves the re-sending problem as well.)

How does this solve the resend issue? When an admin hits the resend invite button, I would still have to remove the user and readd them, correct? Is that the only way to resend that invite email?

Thanks for your help.

[dan]

@stephen said in How long does the email template changePasswordId id last before it expires? How can invitation expiration be implemented?:

Is that the only way to resend that invite email?

Ah, sorry I wasn't clear. I'm not sure you want to use the FusionAuth email templates. If you send the email yourself you'll have more granularity and control.

[stephen]

Added a feature request for this issue: https://github.com/FusionAuth/fusionauth-issues/issues/904