摘要:本文介绍了苹果在 WWDC23 上宣告的对服务端的 2 个 API 弃用,包含verifyReceipt API和App Store Server Notifications V1。一起,本文还供给了相应的兼容迁移主张,包含从 verifyReceipt API 改为 Get Transaction Info API等。此外,本文还介绍了receiptData 旧收据假造问题和苹果新推出的 App Store Server Library 东西包。
一、背景
最近,很多读者跟咱们咨询,关于苹果 App Store API Deprecated 问题,咱们对苹果 WWDC23 和咱们反应的问题而整理本钱文。
苹果在本年 WWDC23 宣告对服务端的2个 API Deprecated(已弃用),意思是API 后续不会有更新和保护,现在还能够用,但未来某天可能会完结不可调用。所以,现在开端需求做兼容和迁移的工作。
参阅:What’s new in App Store server APIs – WWDC23 – Videos – Apple Developer
二、verifyReceipt API 弃用和兼容迁移
2.1 iOS 付出 API 逻辑
现在苹果有2套内购付出的 API:
- StoreKit Original API::现在付出一切 iOS 体系,还没有弃用。
- StoreKit v2:2021年推出,只支撑 iOS 15 以上体系
通过这2个版别的付出 API,付出成功的凭据格局不同:
- StoreKit Original API:付出凭据格局叫 receipt-data,是 Base64编码的加密内容,需求通过苹果 verifyReceipt API 解析出收据信息来校验合法性。
- StoreKit v2:付出凭据是 JWS 签名格局,不需求请求苹果 API 校验,开发者能够本地自行校验合法性(验证签名证书链是苹果的证书)。
2.2 verifyReceipt API 弃用
现在弃用的 verifyReceipt API,便是通过 receipt-data 付出凭据内容校验的接口。
参阅:verifyReceipt | Apple Developer Documentation
提示: 尽管苹果宣告弃用 verifyReceipt API,但 StoreKit Original API 并没有弃用,并且在 visionOS 中还支撑:
参阅:SKPayment | Apple Developer Documentation
所以:
笔者预计未来2~3年内,仍然有大部的 App 运用 StoreKit Original API,导致苹果不会删去相关的 API 和后端验证 verifyReceipt API。但主张开发者,现在开端考虑迁移到新的 API。
2.3 verifyReceipt 兼容迁移
苹果给的迁移和兼容的主张:
参阅:Meet the App Store Server Library – WWDC23 – Videos – Apple Developer
苹果主张开发者,从 verifyReceipt API 改为 Get Transaction History | Apple Developer Documentation API。
有关 Get Transaction History API,能够参阅咱们之前的文章:WWDC21 – App Store Server API 实践总结 –
API 查询到买卖历史记录返回成果只支撑以下状况:
- 主动续期订阅
- 非续订订阅
- 非耗费型运用内购买项目
- 耗费型运用内购买项目:假如买卖被退款、吊销或 app 没有完结买卖处理等。
所以,假如运用这个 API 校验买卖订单号(transactionId),可能需求留意,假如客户端现已调用苹果 finish() | Apple Developer Documentation 或finishTransaction(_:) | Apple Developer Documentation API 后,查询 Get Transaction History API 会返回 404 Not Found。
本年苹果 WWDC23 新供给的 API,能够查询某个 transactionId 收据信息,包体finish的耗费型产品。
- Get Transaction Info | Apple Developer Documentation
参阅:What’s new in App Store server APIs – WWDC23 – Videos – Apple Developer
三、App Store Server Notifications V1 已弃用
App Store Server Notifications V1 和 V2 告诉,是 App Store 服务器主动告诉开发者服务器的 API。比如退款告诉、订阅产品续费成功告诉等。
现在苹果现已弃用 V1 版别的 API:
参阅:App Store Server Notifications V1 | Apple Developer Documentation
V1 和 V2 的首要差异:
- V1 版别:呼应内容是 JSON 格局的数据。
- V2 版别:呼应内容是由 App Store 签名的JSON Web签名(JWS)格局。
V2 支撑更多的告诉类型:
V2 重试更多:
- App Store Server Notifications V1:重试三次;在前次尝试后 6、24 和 48 小时。
- App Store Server Notifications V2:重试五次;在前次尝试后 1、12、24、48 和 72 小时。
V2 JWS 格局中的 payload 解析:
关于 App Store Server Notifications V2 更新内容,能够参阅咱们之前的文章:
- WWDC22 –
- WWDC21 –
相关官方文档:
- V1:App Store Server Notifications V1 | Apple Developer Documentation
- V2: App Store Server Notifications V2 | Apple Developer Documentation
四、receiptData 旧收据假造问题
对于 StoreKit Original API 获取的 receiptData 凭据,苹果在客户端有 2 个 API :
- iOS 7 之前:transactionReceipt | Apple Developer Documentation (已弃用)
- iOS 7 以上:appStoreReceiptURL | Apple Developer Documentation
格局差异: 这 2 个 API 获取的 receiptData 凭据,通过苹果 verifyReceipt API 解析后的格局是不同的。
问题: 现在发现, iOS 7 之前的旧凭据 API,黑产能假造收据中的 Bundle ID !
现在不能假造的字段:
- app_item_id:app id,app 在苹果商铺的仅有标识
- item_id:产品 id,内购商铺在苹果商铺的仅有标识
- transaction_id:买卖 id,苹果的凭据收据的仅有标识(苹果订单号)
主张:
- 服务端要校验以上3个不能不能假造的字段。
- 通过 Apple Store Server API 是查询 transaction_id 做二次校验。
- 假如 app 本身是通过新收据 API 获取,服务端能够直接回绝旧收据的买卖。
提示:苹果对旧凭据收据更新了 SHA-256 加密算法:
即将推出的 AppStore 收据签名媒介证书相关更新 – 最新动态 – Apple Developer
五、App Store Server Library
针对上述的 App Store 校验,苹果现在推出官方的服务器东西包(库),削减开发者接入难度和本钱,一起也避免校验漏洞等问题。
参阅:Meet the App Store Server Library – WWDC23 – Videos – Apple Developer
- Java 版别:github.com/apple/app-s…
- Swift 版别:GitHub – apple/app-store-server-library-swift
- Python 版别:github.com/apple/app-s…
- Node.js 版别: GitHub – apple/app-store-server-library-node
六、总结
本文概述了苹果 App Store 相关 API 和开发者链的改变。首先谈论了 verifyReceipt API 的弃用和开发者迁移到较新 API 的必要性。接着,介绍了 App Store 服务器告诉 V1 的弃用以及 V1 和 V2 告诉之间的差异。另一个重要的论题是旧的 receiptData 格局存在假造凭据的危险。最终,文章介绍了 App Store 服务器库,这是一组旨在简化与苹果 API 集成的东西。这个库供给了 Java、Swift、Python 和 Node.js 版别。
最终,开发者应该马上留意这些改变,并采纳办法及时更新他们的代码。这些改变对开发人员的工作有重要影响,了解这些改变并及时更新代码能够协助开发人员更好地运用苹果 App Store API 和东西,提高开发效率和运用质量,一起也避免旧 API 存在漏洞导致呈现安全危险的问题。
如有问题,欢迎咱们谈论区一起沟通~
咱们是37手游移动客户端开发团队,致力于为游戏职业供给高质量的SDK开发服务。
欢迎关注咱们,了解更多移动开发和游戏 SDK 技能动态~
技能问题/沟通/进群等能够加官方微信 MobileTeam37