training class for Selling In-app Products in Androidが購入要求を行うときにペイロードを使用することを提案:Googleアプリ内課金APIのデベロッパーペイロードとして使用するものは何ですか?
5番目の引数は、ご注文についての補足情報を送信するために使用できる「開発者のペイロード」文字列が含まれています(それが空の文字列を指定できます) 。通常、これは、この購入要求を一意に識別する文字列トークンを渡すために使用されます。文字列値を指定すると、Google Playは購入応答とともにこの文字列を返します。その後、この購入に関するクエリを行うと、Google Playはこの文字列を購入の詳細とともに返します。
セキュリティ勧告:それはあなたが後でこれがそのユーザーによる正当な購入であることを確認することができるように、購入したユーザーを識別するようにアプリケーションを助け文字列を渡すことをお勧めです。消耗品の場合、ランダムに生成された文字列を使用できますが、消耗品でない場合は、ユーザーを一意に識別する文字列を使用する必要があります。
Implementing IAB Purchase pageは、ペイロード値は、独自の安全なサーバー上でチェックする必要があることを追加提案し、同様の勧告があります
セキュリティ勧告:あなたが購入要求を送信、作成この購入要求を一意に識別し、このトークンをdeveloperPayloadに含める文字列トークン。ランダムに生成された文字列をトークンとして使用できます。 Google Playから購入応答を受け取ったら、返されたデータ署名、orderId、およびdeveloperPayload Stringを確認してください。セキュリティを強化するには、自分のセキュアサーバーでチェックを実行する必要があります。 orderIdが以前に処理していない一意の値で、developerPayload Stringが購入依頼で以前に送信したトークンと一致することを確認してください。 GoogleがAPIを実証するために使用される簡易ドライブアプリのソースコードを見てみると
、私はこの警告を見つける:すべてのこれらのメッセージからそう
* WARNING: Locally generating a random string when starting a purchase and
* verifying it here might seem like a good approach, but this will fail in the
* case where the user purchases an item on one device and then uses your app on
* a different device, because on the other device you will not have access to the
* random string you originally generated.
*
* So a good developer payload has these characteristics:
*
* 1. If two different users purchase an item, the payload is different between them,
* so that one user's purchase can't be replayed to another user.
*
* 2. The payload must be such that you can verify it even when the app wasn't the
* one who initiated the purchase flow (so that items purchased by the user on
* one device work on other devices owned by the user).
*
* Using your own server to store and verify developer payloads across app
* installations is recommended.
を、それがに悪いアイデアのように聞こえますペイロードに乱数/文字列を使用します。また、最後の警告を読んだ後は、デバイスIDをペイロードとして渡すことは悪い考えです。異なるデバイス上の同じユーザーで異なるからです。では、開発者のペイロードには何を使用するべきですか?
私のアプリは、サービスにサインインせずにユーザーがアクセスできるローカル機能を提供します。したがって、「ユーザー」という概念はなく、サーバー側コンポーネントもありません。アプリ内購入リクエストは、アプリから広告を削除するアップグレードのためのものです。このようなアプリがペイロード機能を利用するのは意味があるのでしょうか、それとも空の文字列を使ってリプレイ攻撃を受けやすいのですか?
なぜ誰もがそれを簡単にして、アマゾンとリンゴが何をして、外部レシート検証サービスを提供していないのですか? –
@MichaelWiles、androidpublisher API(https://developers.google.com/apis-explorer/#p/androidpublisher/v2/)、特にandroidpublisher.purchases.products.getメソッド – tomrozb