我试图在互联网上找到解决方案,但没有成功.
所以,描述：
首先,应用程序是针对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,则允许他阻止其恢复.
此外,您可以根据自己的需要,根据这些内容推导出自己的逻辑.
如果您有任何疑问,请告诉我.
