iOS В покупке приложения с Rails Backend

Question

У меня возникли некоторые недоумения при создании стратегии покупки приложений для моего приложения для iOS. Некоторая справочная информация ниже;

У меня есть приложение iOS и веб-приложение, которое будет работать в модели подписки. Бэкэнд был разработан в Ruby on Rails.

В настоящее время я пытаюсь разработать автоматическое обновление iOS при покупке приложения. Я наткнулся на пару драгоценных камней, которые помогают проверять поступления на покупку приложений (например, Venice). Я понимаю, что все дело в проверке чеков от бэкэнда, а не на клиенте, - это сделать его безопасным и иметь возможность хранить копию квитанции на вашем собственном сервере.

Я могу предвидеть огромную проблему, как описано ниже;

Пользователь может создать учетную запись с помощью приложения iOS и подписаться на услугу, заплатив X долларов ежемесячно, используя x@x.com apple id. Сделав это, у меня будет запись этого пользователя в моем бэкэнд, включая дату истечения срока его подписки, которая позволит мне отслеживать, продлевает ли он свою подписку или нет. Проблема возникает, когда этот пользователь выходит из приложения и создает другого пользователя. Поскольку его идентификатор apple по-прежнему является x@x.com, и поскольку адрес электронной почты или идентификатор учетной записи не имеет значения при совершении покупки у яблока, срок годности все равно будет на месяц вперед, так как он просто подписался со своей предыдущей учетной записью пользователь будет идентифицирован как уже оплаченный клиент. Boom! теперь его друг может войти в эту учетную запись с помощью веб-приложения и наслаждаться ею, не выплачивая деньги.

Если это имеет смысл для вас, должно быть решение для этого взлома. Я знаю, что Netflix использует IAP от Apple, Spotify используется в течение очень долгого времени.

Также такие драгоценные камни, как Венеция, не содержат подробных документов на их странице github, поэтому я не знаю, разрешена ли эта проблема из коробки. Просто хотел проверить с вами, ребята, и я уверен, что многие из вас подумали об этом.

Answer 1

Если вы приписываете покупку автообновления пользователю в своей базе данных, вы также захотите присвоить original_transaction_id, который находится в квитанции. Сохраните этот идентификатор с помощью expires_date и проигнорируйте или запишите любые квитанции, содержащие тот же original_transaction_id, который получает API, которые уже приписаны другому пользователю в базе данных.

original_transaction_id никогда не изменится для пользователя iTunes, даже если они откажутся от подписки и переподписываются позднее, он останется прежним. Он также останется прежним, если они обновляют или понижают срок действия подписки, когда идентификаторы продуктов имеют одно и то же семейство подписки.

Если вы ищете альтернативу Венеции, посмотрите на драгоценный камень itunes_receipt_validator (полное раскрытие информации: Я являюсь автором). Он проверяет подписи и декодирует как устаревшие транзакционные квитанции, так и суммарные единичные квитанции новее локально без подключения к API Apple, но также предоставляет функциональные возможности для получения обновленной информации о получении и получении от Apple API.