Как мой сервер может надежно пройти проверку подлинности, iPhone в приложении покупают?

Подход Apple, обеспечивающий уязвимость

Сервер может аутентифицировать покупку, выполнив следующие действия :

1. Приложение iPhone получает transactionReceipt после покупки. Пусть iPhone base64 закодирует его (Вы можете использовать это дополнение с открытым исходным кодом к NSData ) и отправить его на свой сервер. (Вы даже можете отправить его как есть, и сервер base64 закодирует его перед проверкой.)

2. Пусть ваш сервер отправит запрос JSON с одним ключом получение-данные с кодировкой base64 transactionReceipt на https://buy.itunes.apple.com/verifyReceipt с использованием HTTP POST. (Инструкции о том, как это сделать на различных серверных языках , см. На этом сайте )

3. Сервер ответит объектом JSON с двумя ключами: status , который является целым числом. и квитанция , которая является повторной квитанцией.

Если статус равен нулю, квитанция действительна, должна быть принята, ненулевое значение означает, что квитанция недействительна.

Безопасные дополнения к Apple's Подход

Однако есть несколько последствий для безопасности. Пользователь может использовать квитанцию ​​другого пользователя, поскольку устройства не привязаны к квитанциям, или пользователь может использовать квитанцию ​​другого продукта, поскольку сервер не проверяет идентификатор продукта квитанции. Чтобы этого не произошло, вам также следует сделать следующее:

1. Когда вы впервые получите квитанцию ​​в приложении, немедленно отправьте его на свой сервер вместе с UUID устройства по защищенному каналу, например HTTPS или сокету SSL. Не храните его нигде, оставьте в памяти.

2. На вашем сервере сохраните пару UUID и квитанции в базе данных.

3. Когда устройство отправляет пару UUID и квитанции, проверьте в своей базе данных, что квитанция еще не использовалась, и убедитесь, что квитанция действительно относится к вашему продукту, проверив идентификатор продукта в квитанции . Квитанция - это просто объект JSON, поэтому ваш сервер может прочитать содержимое, декодируя квитанцию ​​из base64.

4. Вернуть ответ устройству по защищенному каналу, сообщая ему, является ли покупка:

   • Аутентифицирована как новый (разве t в БД и был действительным)
   • Прошла аутентификация (Тот же UUID и пара квитанции уже были в БД)
   • Отклонено из-за неправильного идентификатора продукта
   • Отклонено из-за того, что квитанция уже использовалась с другим UUID.

Поскольку квитанция всегда находится в памяти устройства, и ваше приложение использует UUID устройства ( может быть подделано взломанными устройствами , см. Комментарии), и все покупки вашего продукта регистрируются с помощью UUID устройства на вашем сервере безопасным способом; пользователь не может использовать квитанцию ​​другого пользователя для подтверждения покупки, а также они не могут использовать квитанцию ​​от другого продукта, поскольку вы проверяете это.

Вы также можете проверить другие поля из квитанции, если хотите проверить другие детали сделка. Например, если ваш продукт является подпиской, вы Я тоже захочу посмотреть на дату транзакции.

Кроме того, пользователи не могут притворяться вашим сервером, располагая устройство в частной сети с хостом с тем же именем, что и ваше, поскольку у них не будет вашего SSL сертификат.

Соображения по поводу сбоев

Поскольку сбой может произойти между получением устройством пользователя квитанции и ее проверкой на вашем сервере (например, если пользователь теряет соединение или ваш сервер недоступен для обслуживания), вам также следует разрешить пользователь «повторно авторизуется». При повторной авторизации необходимо получить квитанцию ​​из магазина (с использованием Восстановленной транзакции ) и повторно отправить ее на сервер, как если бы это была новая покупка. Это должно использоваться редко, но должно быть доступно, чтобы пользователю не пришлось повторно покупать продукт в случае сбоя сети.

Учет нескольких устройств

Это означает, что если пользователь хочет использовать приложение на нескольких устройствах, ему придется покупать продукт несколько раз. Это может быть желаемым эффектом, но вам, вероятно, следует проинформировать своих пользователей перед покупкой, поскольку они могут ожидать, что смогут использовать контент на всех устройствах, связанных с их учетной записью.

Если квитанция также содержит информацию об учетной записи iTunes, аутентификация может использовать это, чтобы позволить пользователям обмениваться контентом между всеми своими устройствами (но не между своими друзьями).

Не думаю, что можно привязать квитанцию ​​к устройству.

Насколько я понимаю, вам разрешено устанавливать приложение на несколько устройств без дополнительных затрат. Привязка его к устройству будет означать, что если вы, например, обновите / смените телефон, вам придется снова покупать все приложения.