Ability to receive magic URL as part of API response.

[ravindrasingh-code]

Currently, the magic URL is sent directly to the user's email address, which is very limiting. We should be able to consume magic URLs via multiple channels, for example, SMS, Whatsapp and etc. For this purpose, it will be better if it can be returned as part of the API response itself. Also for our use case, most of our user base uses SMS and WhatsApp as their primary mode of communication rather than email.
This can be a really cool feature to have and I am sure will add a lot of value to the community.

[Meldiron]

Notes:

• Use-case is custom authentication flow using Appwrite functions
• Problem is the limitation and no way to use 3rd party channels for authentication
• Suggested solution is to create 2 new endpoints (for server-side) (just like MagicURL) but instead of sending an email with a URL, it returns the URL as a response (string).

First, let me start by specifying that this API endpoint has to be a new one and MagicURL should be left as is - send an email.

Also, we need to make sure this is an API endpoint for server-side SDKs because the client should never see this URL with secrets directly after sending a request to create one.

With that said, I would also like to specify that channel doesn't need to be just mobile, but whatever... Let's go crazy... It can be Discord bot, integration to already existing company auth flow, or even some custom NFC reader. The idea is to allow serverless authentication using any other devices by communicating with any 3rd parties.

I can see an issue with using such a server-side endpoint, because visitors can execute functions only once they are logged in... In our case, the visitor's intention is to log in by executing the function.

So in short - We want to allow server-side to create a custom session

We don't need to worry about storing authentication tokens into cookies, because this will be done by our ClientSDK... The process after visiting the link will be the same - Website will hit the confirmation endpoint with the secrets from the query parameters. If a developer decides to parse the URL on the server-side and only take secrets from that, it's fine, but then he needs to make sure to follow the correct steps to finish the login process and store cookies from the response.

A possible question could be What would be the difference between this and long-living JWT?.

[gepd]

A possible question could be What would be the difference between this and long-living JWT?.

Hey @Meldiron long living JWT will need an extra endpoint to check a valid JWT
currently we just need an endpoint to generate the magic link (server side) and updateMagicURLSession (client-side) will handle the rest right?

There is any workaround for this in version 0.13? I mean, I need to create a session sending a message/link from whatsapp I don't how can I do this with the current account API