Fictional phone numbers with pre-defined OTP for testing (Like in Firebase)

[DriesCruyskens]

Firebase allows you to create fictional phone numbers with a pre-defined OTP. This is very useful when running tests and App Store reviewers need a test account so they can get past authentication without using their personal phone number. More info on Firebase's functionality and its benefits here.

I can't find any info whether Supabase or GoTrue support this functionality. Is there a possibility it might be implemented eventually or does anyone know of a different solution to this problem?

EDIT:

The solution I ended up using is a trigger function on auth.users which overwrites the confirmation_token value on INSERT or UPDATE.

-- This functions resets the confirmation token to a known value to enable logging in without receiving an SMS.
-- Use for developing, testing/cicd and app store reviewers.
CREATE FUNCTION test_credentials()
RETURNS TRIGGER
AS $$
BEGIN
    IF (NEW.phone = ANY(array['<test-phone1>', '<test-phone2>'])) THEN
        NEW.confirmation_token := '654321';
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER test_credentials BEFORE INSERT OR UPDATE ON auth.users FOR EACH ROW EXECUTE PROCEDURE test_credentials();

[enqqi]

Where you able to find a solution?

[DriesCruyskens]

updated the post with my solution

[enqqi]

Awesome. Will check it out!

[bhvngt]

@DriesCruyskens Thank you for your solution. Similar to your solution, I tried entering confirmation_token directly in one of the test user's record in auth.users. Then I tries to get the session by using adminClient.auth.api.verifyOTP({phone: <phoneNum>, token: <insertedToken>}). However, I am getting, error: { message: 'Token has expired or is invalid', status: 401 } } error.

Am I doing it correctly or am I missing some step here. Thanks in advance for your help.

[DriesCruyskens]

If I remember correctly I had the same result and this is normal. The only time it works is when setting the confirmation_token right at row creation or update by intercepting it using a trigger. I assume something is going on behind the scenes that does not allow the token to be set manually afterwards.

[bhvngt]

Thanks for your reply @DriesCruyskens.

Finally figured out the issue. Along with confirmation_token, I also had to set confirmation_sent_at to current timestamp. gotrue calculates the token expiry based on this field. In case of null it rejects the verification request.

It worked both ways, manually or through a trigger as long as this field is set.

[ilbertt]

@DriesCruyskens for for me too, with the confirmation_sent_at fix by @bhvngt. Thanks you both!

[ilbertt]

@bhvngt it works for me, in the sense that I can use the "fake" otp that gets inserted in the table by the triggered function but gotrue still attempts to send an SMS to that number. And since the number is not real, MessageBird (I use it instead of Twilio) receives the request and attemps to send an SMS anyways. Do you have some hints? Looking at gotrue source code it seems there's no way to avoid calling the sms provider

[bhvngt]

@Luca8991 If you would like your app to generate OTP then you may want to completely bypass gotrue by sending and verifying otp using provider's api and then upon successful verification directly creating the user from your backend using supabase service role

[ilbertt]

@bhvngt so basically this means that I need to create a custom HTTP endpoint that receives all otp requests and handles test phone numbers properly, right?
Considering also my reply, wouldn't it be a feature needed in Supabase? This could also work for email/password users and maybe also for 3rd party providers.

[jordiup]

@DriesCruyskens for for me too, with the confirmation_sent_at fix by @bhvngt. Thanks you both!

That's exactly it. Here are some final pieces of the puzzle I figure out when doing this:

• run this code by clicking 'SQL Editor' and pressing run
• you have to add in the line NEW.confirmation_sent_at := now(); for it to work
• you can then find the function/make final edits by going 'Database' > 'Functions'
• you'll need to alter test-phone1 to match your chosen number/country codes

-- This functions resets the confirmation token to a known value to enable logging in without receiving an SMS.
-- Use for developing, testing/cicd and app store reviewers.
CREATE FUNCTION test_credentials()
RETURNS TRIGGER
AS $$
BEGIN
    IF (NEW.phone = ANY(array['<test-phone1>', '<test-phone2>'])) THEN
        NEW.confirmation_token := '654321';
        NEW.confirmation_sent_at := now();
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

[ilbertt]

One cool improvement I see so far would be to have a table in auth schema called like test_users that holds the fictional phone numbers with their fictional OTP code, and maybe some other "metadata" like a label. The triggered function could then simply query this table and check for the existence of that number.
I'd like to open a PR for this, but I think it requires more effort than creating a table and a trigger. What are your thoughts about this?

[bhvngt]

I am not sure if this should be a core feature of supabase. What @WesleyYue have suggested is pretty much what I have done to test OTP.

[WesleyYue]

For anyone interested in making this work for email: #10298 (comment)

[stravag]

If you're like me and ran into some issues with this cool approach: the phone is saved without the leading "+".

Here's the complete working setup kudos to everybody in this discussion.

-- This functions resets the confirmation token to a known value to enable logging in without receiving an SMS.
-- Use for developing, testing/cicd and app store reviewers.
CREATE FUNCTION test_credentials()
RETURNS TRIGGER
AS $$
BEGIN
    IF (NEW.phone = ANY(array['41791111111', '41792222222'])) THEN
        NEW.confirmation_token := '123456';
        NEW.confirmation_sent_at := now();
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER test_credentials BEFORE INSERT OR UPDATE ON auth.users FOR EACH ROW EXECUTE PROCEDURE test_credentials();

[meraj759]

-- This functions resets the confirmation token to a known value to enable logging in without receiving an SMS.
-- Use for developing, testing/cicd and app store reviewers.
CREATE FUNCTION test_credentials()
RETURNS TRIGGER
AS $$
BEGIN
IF (NEW.phone = ANY(array['41791111111', '41792222222'])) THEN
NEW.confirmation_token := '123456';
NEW.confirmation_sent_at := now();
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER test_credentials BEFORE INSERT OR UPDATE ON auth.users FOR EACH ROW EXECUTE PROCEDURE test_credentials();

[iriealex]

This does not work for me. (I am using Twilio) !
The OTP is sent to the test phone number and the OTP is not what I set (it is a dynamic one).

[corasan]

Same for me, I am trying this and doesn't work at all.

[jordiup]

I'm sleuthing this now...

Looks like they changed confirmation_token in auth.users to be hashed?

I don't think I'll have time to properly look into this, but you can view the go-true changelog here:
https://github.com/supabase/gotrue-js/releases?page=3

Have a look and see what's changed in the DB/API

Good luck

[stravag]

I found a solution. @jordiup had the right idea: the token is now hashed. See also: https://github.com/supabase/gotrue/blob/7fbb0ad56bd01c3e603e495aa514ec4e3bf35c7a/internal/api/verify.go#L462 (code at time of writing)

This adjusted trigger function worked for me.

-- This functions resets the confirmation token to a known value to enable logging in without receiving an SMS.
-- Use for developing, testing/cicd and app store reviewers.
CREATE FUNCTION test_credentials()
RETURNS TRIGGER
AS $$
BEGIN
    IF (NEW.phone = ANY(array['41791111111', '41792222222'])) THEN
        NEW.confirmation_token := encode(sha224(concat(NEW.phone,'123456')::bytea), 'hex');
        NEW.confirmation_sent_at := now();
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER test_credentials BEFORE INSERT OR UPDATE ON auth.users FOR EACH ROW EXECUTE PROCEDURE test_credentials();

[stravag]

Unfortunately this will still attempt to send the SMS. I ended up implementing a "switch" in the flutter app for test numbers, that actually sends emails instead of sms: prefix+<TEST-PHONENUMBER>@domain.tld ... it's a bit hacky but works.

if (_isTestPhoneNumber(phoneNumber)) {
        await supabaseAuth.signInWithOtp(email: _toTestEmail(phoneNumber));
} else {
        await supabaseAuth.signInWithOtp(phone: phoneNumber);
}

For these test emails I still use the above trigger (modified to check for emails with a certain pattern) to ensure that the OTP is fixed (for App Store Reviewers and other Testers)

[LunatiqueCoder]

Even hackier, but seems to be working? :/ I don't ship this in production though.

create function fake_credentials(phone_number text) returns text
    security definer
    language plpgsql
as
$$
BEGIN
    update auth.users
    set confirmation_sent_at=now(),
        confirmation_token=encode(sha224(concat(phone_number,'123456')::bytea), 'hex')
    where auth.users.phone = phone_number;

    RETURN 'done!';
END;
$$;

Then in JavaScript:

    FICTIONAL_NUMBERS.includes(phone) && __DEV__
      ? await supabase.rpc('fake_credentials', {phone_number: phone})
      : await supabase.auth.signInWithOtp({phone});

[jordanful]

This isn't working for me — it is creating the user, but the token is invalid.
EDIT: The issue was that my existing formatter wasn't formatting the phone number in a way that the Postgres function expected. All good here. Thanks y'all.

[cspecter]

How did you all get this to work. I am running the function and it is creating the user. Send the phone as '+1800551212' and '18005551212' and neither works. I checked that both this Sha224 and the code in Go are creating the same hash.

In flutter:

// When sending creating the code
if (phone == fakeNumber) {
        print('fake credentials $phone');
        await Supabase.instance.client.rpc('fake_credentials',
            params: {'phone_number': phone.replaceAll('+', '')});
        return;
      } else {
        await Supabase.instance.client.auth.signInWithOtp(
          phone: phone,
          shouldCreateUser: true,
        );
      }

// When authorizing using the fake code
await Supabase.instance.client.auth.verifyOTP(
          phone: phone,
          token: code,
          type: OtpType.sms,
        );

[cspecter]

Never mind. This is because of the same Twilio Verify error noted below. I switched to Message Bird and everything works correctly.

[jordanful]

I just found this option in the Supabase dashboard. 🎉 (Auth -> Providers -> Phone)

[cspecter]

This is also blocking us from getting our app approved using Twilio Verify.

[azlekov]

@cspecter any workaround?

[cspecter]

Yes. We switched to MessageBird from Twilio Verify. It took a little longer to get approved and cost per message, but everything works correctly. I think Supabase will need to update their library to get test numbers working with Twilio Verify.

[azlekov]

@cspecter I'm switching temporary to MessageBird as well. I notice that even with MessageBird the test phone numbers are not working locally, only on production. Did you try using test otp locally? Can you share some configuration to compare?

[auth.sms]
enable_signup = true
enable_confirmations = true

[auth.sms.test_otp]
359888888888 = "888888"

[sumersao]

I see this gotrue release which contains a patch for the twilio OTP issue. Pardon my ignorance, but has it been released in supabase-js? It seems like in the releases, supabase-js only has gotrue version 2.54.2.

How could I anticipate it bumping the dependency to gotrue v2.98.1? Or am I supposed to pull this version of gotrue and use it in my repo separately somehow?

[iriealex]

This problem has now been resolved in the Supabase Dashboard, has'nt it ?

…

On Fri, Dec 22, 2023 at 5:18 AM meraj759 ***@***.***> wrote: -- This functions resets the confirmation token to a known value to enable logging in without receiving an SMS. -- Use for developing, testing/cicd and app store reviewers. CREATE FUNCTION test_credentials() RETURNS TRIGGER AS $$ BEGIN IF (NEW.phone = ANY(array['41791111111', '41792222222'])) THEN NEW.confirmation_token := '123456'; NEW.confirmation_sent_at := now(); END IF; RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE TRIGGER test_credentials BEFORE INSERT OR UPDATE ON auth.users FOR EACH ROW EXECUTE PROCEDURE test_credentials(); — Reply to this email directly, view it on GitHub <#5358 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUYYUXREUTV3DT6ODFKUYGLYKUJZHAVCNFSM5NXKR5P2U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TOOJSGQ2DQOI> . You are receiving this because you commented.Message ID: ***@***.***>