Endpoint to get a password reset link or token to be able to implement a custom password reset flow

[saibotma]

🚀 Feature

It would be great to have an endpoint where a server could request a password reset link or token for a specific user.
The server could then send this link to the user using his own emailing system, SMS, etc. and would not be limited to the password reset feature currently available in Appwrite.

Firebase can be used as an orientation: https://firebase.google.com/docs/auth/admin/email-action-links

@eldadfux suggested a temporary, easy to implement workaround solution on Discord:

I think the only way to do this would be to parse Appwrite recovery email for the generated secret token. If you could raise this as an issue we can add that token to the POST /v1/account/recovery response object, and then you can just take the userID and the token from the response and transmit them to the user anyway you like

Have you spent some time to check if this issue has been raised before?

yes

Have you read the Code of Conduct?

yes

Pitch

As stated above.

[saibotma]

We @tappeddev need this feature for a next software project. Without this feature it is not possible for us to use appwrite.
We would love to contribute and create a PR.
Do you have any quick tips on where to start and what we have to keep in mind?

[eldadfux]

@saibotma I think there are only 2 missing pieces to help you make this feature possible, but please confirm I'm getting it right.

1. You need a way to get the secret hash after using the password token creation endpoint (https://appwrite.io/docs/client/account?sdk=web#createRecovery) response, as this is the only thing you're missing in order to not have to parse the email message for the token itself and submit the confirmation endpoint (https://appwrite.io/docs/client/account#updateRecovery) successfully?

2. You need a way to make sure that Appwrite doesn't send any emails by its own on password reset?

And just a general question, is this a workaround for another issue with the email template or way to overcome this missing SMS recovery?

[JulianBissekkou]

Hey @eldadfux I am a developer at @tappeddev as well and I am helping @saibotma with this project.

I would like to explain the exact problem again to make sure that we find the correct solution:

Problem:
We have multiple users that are connected to one E-Mail address.
In appwrite, every user has a unique email since we can't link multiple users to one E-Mail. The unique emails do not exist and are generated by us.
In case the user forgets the password, we have to send the password reset link to the correct E-Mail address which is stored in our database.

Proposed Solution:
As described by @saibotma we would like to get the password reset link from the API and send the mail by ourselves.
We are currently doing this for another system where we are using firebase, but we would like to move to appwrite!

And just a general question, is this a workaround for another issue with the email template or way to overcome this missing SMS recovery?

The reason for this workaround is mostly because of the problem described above and also because of the template issue.
SMS recovery would be a nice addition but it's not our priority now.

[eldadfux]

OK so here are a few thoughts:

1. Unlike Firebase we wouldn't want to couple our API with any specific email links, but we rather prefer to provide all the required data you need to be able to build this link on your own. At the end of the day the only missing piece to build the link is the secret hash which is currently only exposed in the email being sent by Appwrite.

2. Disabling system mails should be pretty easy, we can skip the email sending if the SMTP hostname is empty or by using another env var that we can choose.

3. We could create a new webhook event (account.password.reset or something similar to match our conventions) that will contain both the user ID, token ID, and secret hash in its payload, this can trigger your custom HTTP endpoint where you can send your custom emails. When cloud functions will be available same logic can be applied but without needing to host your own HTTP endpoint.

4. We can expose a reset token endpoint in the users API to be accessible from a server integration, but it would be problematic to expose the secret because we save a hash version of it in the DB and we only compare both hashes, but we don't have any way to know the original secret sent to the user. We don't store the original secret in order to protect against a potential DB leak.

[JulianBissekkou]

I think a combination of 1 and 2 fits best and I think the API of 1 is handy for future features.
With Option 3 we still need to disable the system emails, right? 🤔

Which options would you choose, when looking at the complexity of this PR?
We would like to get this feature done in a maximum of 3 weeks.

Thanks for taking the time! ☺️

[eldadfux]

I think 2+3 should be pretty straight forward. 2 will be really simple, for 3 we'll need a small tweak to make sure the secret key is being passed to the new webhook event payload, by default its hidden, but I think its doable as we've done similar things on deletion events where the http payload is different from the webhook payload.

Nothing major in terms of updating tests or docs.

If sound reasonable we can collaborate on Discord to get this working for you.

[eldadfux]

Both features (new webhooks & disbale SMTP) are now reviewed and merged. You can test the on Appwrite 0.7.x branch or by using the dev tag on Docker hub. Up-to-date docs will be published on Appwrite.io with relevant labels for features enabled only on v0.7. Please reach out if you need any helps.

[eldadfux]

v0.7 is finally out with all the updates available 🥳