我试图在互联网上找到解决方案,但没有成功.
所以,描述:
首先,应用程序是针对iOS7的.其次,我有一些项目(type = Non-Renewing Subscription).因此,用户可以购买一件或多件物品,然后他应该手动更新它们(再次购买).
应用程序向服务器端发送收据,我向Apple发出请求并获得带有大量in_app收据的结果.就像是:
"in_app":[ { "quantity":"1","product_id":"...","transaction_id":"...","original_transaction_id":"...","purchase_date":"...","purchase_date_ms":"...","purchase_date_pst":"...","original_purchase_date":"...","original_purchase_date_ms":"...","original_purchase_date_pst":"...","is_trial_period":"..."},{ "quantity":"1","is_trial_period":"..."} ]
因此,“in_app”中的每个“收据”都有transaction_id.但我如何识别当前购买的transactionId?我想验证它,并确保这是独一无二的.
我担心的是:如果有人会收到一张有效收据,他就可以破解我们的服务器端API,并使用相同的有效收据进行无限数量的应用内购买.
我应该以某种方式解密并检查transaction_id的“原始”收据,即我发送给Apple进行验证的收据?
任何帮助/建议将受到高度赞赏.
先感谢您.
问候,
马克西姆
解决方法
如果您浏览此页面上的不同字段,您会发现
Original Transaction Identifier::
For a transaction that restores a previous transaction,the transaction identifier of the original transaction. Otherwise,identical to the transaction identifier.
This value corresponds to the original transaction’s transactionIdentifier property.
All receipts in a chain of renewals for an auto-renewable subscription have the same value for this field.
因此,对于非自动续订订阅,您必须跟踪服务器端的两件事:
>您正在使用itunes服务器验证的收据的原始事务标识符,将其与数据库中的用户ID相关联.
>您从客户端收到的请求是购买还是恢复购买.
一旦你掌握了这两件事,就可以在这两个参数上写下你的逻辑,如下所示:
::如果请求的类型为“Purchase”,并且您已将该收据的原始交易标识符与其他用户ID相关联,则可以阻止该购买.
::如果请求的类型为“Restore Purchase”,并且请求来自与您的数据库中原始事务标识符关联的相同用户ID,则允许他阻止其恢复.
此外,您可以根据自己的需要,根据这些内容推导出自己的逻辑.
如果您有任何疑问,请告诉我.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。