Вопрос или проблема
RevenueCat REST API не работает с публичным API ключом Stripe
В моем проекте на Flutter мне удалось добавить платный доступ благодаря RevenueCat для Android, iOS и macOS.
Теперь я хочу достичь того же для Windows и Linux. К сожалению, пакет purchases_flutter недоступен для Windows или Linux.
Поэтому я выбрал создать простую ссылку для платежа с помощью Stripe и подключить Stripe к RevenueCat. Тогда я смогу взаимодействовать с RevenueCat из версий моего приложения для Windows и Linux, используя REST API RevenueCat.
Вот задачи, которые мне нужно решить:
- перечислить мои предложения
- проверить, купил ли пользователь мой продукт с одноразовым платежом или нет
- восстановить покупку одноразового платежа
И вот моя проблема:
- если я попытаюсь выполнить перечисленные выше задачи, используя только мой публичный API-ключ Stripe (например, с помощью Postman), следуя документации, я получаю ошибку о том, что мой ключ недействителен.
- если я делаю то же самое, но с секретным ключом, который я создал с правильными авторизациями, это работает.
И это действительно раздражает меня, поскольку я не хочу иметь дело с бэкендом только для хранения приватного ключа. Кроме того, я не понимаю, почему мне нужно работать с приватным ключом в этом случае, когда для работы пакета purchases_flutter нужен только публичный API-ключ.
Есть ли возможность выполнить вышеуказанные задачи, используя только публичный API-ключ Stripe? Или безопасно использовать секретный ключ, который будет полностью посвящён вышеуказанным задачам с минимальными авторизациями, которые я могу хранить в своем приложении?
Ответ или решение
Для успешной интеграции RevenueCat с Stripe в вашем приложении на Flutter для Windows и Linux, действительно потребуются некоторые нюансы, касающиеся работы с API и использованием ключей.
Почему не работает публичный ключ
Проблема, с которой вы столкнулись, связана с тем, что публичный API ключ Stripe предназначен исключительно для клиентских операций, таких как создание платежных форм и сбор данных о картах. В отличие от него, RevenueCat API требует аутентификации с помощью личного (секретного) ключа, поскольку это серверные вызовы, которые требуют защищенности для управления пользовательскими данными и подписками.
Аутентификация RevenueCat
RevenueCat использует секретные ключи API для аутентификации при выполнении операций, таких как:
- Список предложений (offerings)
- Проверка покупок
- Восстановление покупок
Ваш случай требует использования секретного ключа RevenueCat для выполнения этих операций. Использование публичного ключа для доступа к сервисам RevenueCat не поддерживается.
Как безопасно хранить секретный ключ
Если вы не хотите разрабатывать бекенд-решение для хранения секретного ключа, вы можете принимать некоторые меры предосторожности при хранении и использовании секретного ключа в приложении:
- Простая оболочка: Секретный ключ можно использовать на клиенте, если хранить его за пределами кода, например, в файле конфигурации, который не будет включен в репозиторий.
- Шифрование: Рассмотрите возможность шифрования секретного ключа и его расшифровки в коде при использовании.
- Привилегии и доступ: Создайте специализированный секретный ключ с минимально необходимыми правами, ограничив доступ только к нужным вам операциям.
Рекомендации по архитектуре
- Мобильное и настольное приложение: Даже если ваш проект сейчас не требует серверной части, рекомендуется, по мере роста проекта, рассмотреть разработку небольшого бекенда, чтобы управлять аутентификацией и доступом более эффективно.
- Изоляция функциональности: Подумайте о том, чтобы изолировать функциональность, связанную с RevenueCat, создавая API-класс, который будет делать запросы к RevenueCat и обрабатывать ответы, тем самым повышая уровень абстракции и безопасность кода.
Заключение
На данный момент для вашего сценария работы с RevenueCat через Stripe вам необходимо использовать секретный ключ. Нет возможности обходиться только публичным ключом для выполнения необходимых операций в RevenueCat. Если вы будете хранить секретный ключ, делайте это с умом и предусмотрительно, минимизируя риски. По мере возможности, рассмотрите возможность разработки серверной части для более безопасного управления аутентификацией.