🚀 Feature: Custom Phone Auth Adapter

[mdmohsin7]

🔖 Feature description

A Custom Phone Auth Adapter which will make a call to some X endpoint. The X endpoint will send the OTP SMS using any of the SMS provider the user has implemented for that endpoint. The endpoint will receive OTP as input from Appwrite. This way the user will be able to change their SMS Provider at any instance of time in X's implementation without making any changes in Appwrite configuration.

🎤 Pitch

This would allow users to use any SMS Provider to send OTP messages irrespective of whether that provider is supported by Appwrite or not. This would also allow the users to use SMS Providers which do not provide a REST endpoint and instead provide their SDKs to interact with their service.

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

• [X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• [X] I have read the Code of Conduct

[adarsh-jha-dev]

Hey @mdmohsin7 , could you please assign me this issue?

[stnguyen90]

@mdmohsin7, thanks for raising this issue! 🙏🏼 There isn't a standard on all the different options for how to send an SMS, so it would be challenging to create a generic one. The best thing to do is to raise an issue for a new SMS adapter and then the core team or someone from the community can contribute. Did you have one in mind?

[mdmohsin7]

@mdmohsin7, thanks for raising this issue! 🙏🏼 There isn't a standard on all the different options for how to send an SMS, so it would be challenging to create a generic one. The best thing to do is to raise an issue for a new SMS adapter and then the core team or someone from the community can contribute. Did you have one in mind?

Yes exactly! Since there isn't a standard, I was thinking what if we create sort of a generic adapter? That is let's say I have a separate serverless function whose job is to send OTPs to specified phone number through Twilio. In the standard adapter I will make call to this serverless function and will pass the OTP generated by Appwrite to it. Now if in future, if I plan to move away from Twilio and let's say I want to use AWS SNS to send OTPs, in that case I won't actually have to make any changes at the Appwrite's end. Instead I'll just have to update the logic in that serverless function. This way I wouldn't have to worry whether the SMS provider is supported by Appwrite or not and I won't have to request the Appwrite team to add support for a new SMS provider.

The process implementation for this custom adapter will look something like this:

    protected function process(SMS $message): string
    {
        return $this->request(
            method: 'POST',
            url: "https://api.example.com/sendOtp",
            body: \http_build_query([
                'Body' => $message->getContent(),
                'From' => $message->getFrom(),
                'To' => $message->getTo()[0],
            ]),
        );
    }

Please let me know what do you think about this approach.

[stnguyen90]

@mdmohsin7, that's a bit too niche to really be worthwhile...That said, if you're already implementing something custom, you could try to make it match Infobip and use that adapter (once we release it).

[mdmohsin7]

@mdmohsin7, that's a bit too niche to really be worthwhile...That said, if you're already implementing something custom, you could try to make it match Infobip and use that adapter (once we release it).

That can be done. Is there any info as to when it will be released?

[catalystech]

@mdmohsin7, that's a bit too niche to really be worthwhile...That said, if you're already implementing something custom, you could try to make it match Infobip and use that adapter (once we release it).

using appwrite for a project in China. Would like to use either netease or alicloud SMS service. A generic adapter would be very helpful