Как создать постоянные тестовые аккаунты для ревьюеров App Store с Supabase

Краткое содержание

Если вы создаёте мобильное приложение с аутентификацией Supabase с использованием Magic Links или OTP, правила App Store требуют предоставить постоянный демо-аккаунт. Используйте триггер PostgreSQL для перехвата определённых тестовых email-адресов и установки их токенов аутентификации в предсказуемое значение (123456).

Быстрая настройка:

1. Откройте SQL Editor в Supabase
2. Создайте функцию-триггер, которая устанавливает recovery_token для тестовых email
3. Предоставьте ревьюерам: Email reviewer1@example.com или reviewer2@example.com, Код 123456

Проблема

Правила App Store требуют предоставить демо-аккаунт с постоянным именем пользователя и паролем. Однако, если ваше приложение использует Magic Links или OTP (одноразовый пароль) через email, коды входа случайны и истекают. Вы не можете дать ревьюеру Apple доступ к вашему Gmail-ящику для проверки кода.

Решение

Вы можете использовать Триггер PostgreSQL в панели управления Supabase для перехвата определённых "тестовых" email-адресов и принудительной установки их токенов аутентификации в предсказуемое, жёстко заданное значение.

Вот как это настроить в 3 шага.

Шаг 1: Откройте SQL Editor

Перейдите в панель управления Supabase, откройте SQL Editor и создайте новый запрос.

Шаг 2: Создайте функцию и триггер

Скопируйте и вставьте код ниже. Этот скрипт отслеживает определённые email-адреса (например, ваши аккаунты ревьюеров) и вручную устанавливает их recovery_token в предсказуемый хеш на основе email и секретной строки (в данном случае '123456').

Он также корректирует временную метку (recovery_sent_at), чтобы токен считался "свежим" и действительным системой.

-- 1. Создайте функцию для перехвата генерации токена
CREATE OR REPLACE FUNCTION preset_otp()
RETURNS trigger
AS $$
begin
    -- Определите ваши тестовые email здесь
    IF (NEW.email = ANY(ARRAY['reviewer1@example.com', 'reviewer2@example.com'])) then
        -- Принудительно установите recovery_token как хеш email + '123456'
        NEW.recovery_token := encode(sha224(concat(NEW.email, '123456')::bytea), 'hex');
        -- Сделайте так, чтобы токен выглядел как только что отправленный
        NEW.recovery_sent_at := NOW() - INTERVAL '2 minutes';
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;
 
-- 2. Прикрепите триггер к таблице auth.users
CREATE OR REPLACE TRIGGER preset_otp 
BEFORE INSERT OR UPDATE ON auth.users 
FOR EACH ROW EXECUTE PROCEDURE public.preset_otp();

Примечание: Email-адреса reviewer1@example.com и reviewer2@example.com настроены для использования жёстко заданного кода 123456.

Шаг 3: Обновите логику вашего приложения (Опционально)

В зависимости от того, как ваш экран входа проверяет пользователей:

1. Для Magic Links: Теперь вы можете построить magic link вручную, потому что знаете логику токена.
2. Для OTP: Если вы проверяете коды, убедитесь, что ваш бэкенд или edge-функция обрабатывает проверку, распознавая эти конкретные email и принимая жёстко заданную логику, предоставленную в триггере.

Почему это работает

Это создаёт "чёрный ход" только для определённых вами email. Обычные пользователи продолжают получать случайные, безопасные коды по email, но ваш ревьюер App Store может войти, используя предоставленные вами учётные данные, без необходимости доступа к email.

Шаблоны для отправки в App Store

Вот текстовые шаблоны, которые вы можете скопировать и вставить непосредственно в App Store Connect (в разделе App Review Information) и Google Play Console (в разделе App Access).

Вариант 1: Если ваше приложение запрашивает 6-значный код (OTP)

Поскольку вы жёстко задали логику (используя 123456 на основе вашего SQL-фрагмента), используйте это сообщение, чтобы проинструктировать ревьюера не ждать реального email.

Для App Store Connect:

Информация о демо-аккаунте:
 
Имя пользователя/Email: reviewer1@example.com
Код верификации: 123456
 
Примечания:
Этот аккаунт настроен со статическим одноразовым паролем (OTP) для целей проверки. Вам не нужно получать доступ к внешнему почтовому ящику. Пожалуйста, введите email выше, и когда будет запрошен код верификации, введите "123456" для немедленного входа.

Для Google Play Console (App Access):

1. Выберите "All or some functionality is restricted" (Вся или некоторая функциональность ограничена).
2. Нажмите "Add new instructions" (Добавить новые инструкции).
3. Name: Вход в тестовый аккаунт
4. Phone/Email: reviewer1@example.com
5. Password/OTP: 123456
6. Any other instructions:

   Это предварительно настроенный тестовый аккаунт. Код OTP жёстко задан как "123456" для этого конкретного email-адреса, чтобы обойти ограничения верификации по email во время проверки.

Вариант 2: Если ваше приложение использует Magic Links (без ввода кода)

Если ваше приложение обычно требует нажатия на ссылку в email, но вы изменили поток для принятия пароля или ручного ввода для ревьюеров:

Информация о демо-аккаунте:
 
Email: reviewer1@example.com
Пароль/Секрет: 123456
 
Примечания:
Наше приложение обычно использует magic links для аутентификации. Для процесса проверки мы включили обход для указанного выше email-адреса. 
 
Пожалуйста, введите email, и если появится поле для кода или пароля (или если вы используете отладочный поток входа), введите "123456", чтобы продолжить без проверки email.

Резюме

Это решение позволяет вам:

• ✅ Предоставлять постоянные демо-аккаунты для ревьюеров App Store
• ✅ Обходить верификацию по email для определённых тестовых аккаунтов
• ✅ Поддерживать безопасность для обычных пользователей (они всё ещё получают случайные коды)
• ✅ Использовать предсказуемые учётные данные (reviewer1@example.com / reviewer2@example.com с кодом 123456)

Триггер PostgreSQL перехватывает генерацию токенов аутентификации только для указанных тестовых email-адресов, обеспечивая доступ ревьюеров App Store к вашему приложению без необходимости проверки почтовых ящиков.