Googleアプリ内課金APIのデベロッパーペイロードとして使用するものは何ですか？

Question

training class for Selling In-app Products in Androidが購入要求を行うときにペイロードを使用することを提案：

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をペイロードとして渡すことは悪い考えです。異なるデバイス上の同じユーザーで異なるからです。では、開発者のペイロードには何を使用するべきですか？

私のアプリは、サービスにサインインせずにユーザーがアクセスできるローカル機能を提供します。したがって、「ユーザー」という概念はなく、サーバー側コンポーネントもありません。アプリ内購入リクエストは、アプリから広告を削除するアップグレードのためのものです。このようなアプリがペイロード機能を利用するのは意味があるのでしょうか、それとも空の文字列を使ってリプレイ攻撃を受けやすいのですか？

Answer 1

InAppの購入に関する私の知識は、古いv2ライブラリからのものです。私は最新のv3で作業していません。しかし、うまくいけば私はまだ助けになることができます。

はい、追加のセキュリティ機能として開発者のペイロードを使用することは間違いなく役立つでしょうが、あなたはおそらくより客観的なジレンマであるべきか否かにかかわらず、私の場合、顧客はインボックス購入後に200MBのファイルをダウンロードする必要があるため、クライアントには既にサーバーが混在しています。開発者のペイロードを使用して、ダウンロードが許可されたファイルに関する情報を保存しました。この情報は、ダウンロードされたファイルをどのように処理するかをアプリに伝える上で重要でした。

ローカルのverifyPurchase()メソッドをサーバー呼び出しでオーバーライドすることでセキュリティを強化しました。私たち自身のノンスをチェックするIEを提供しています。それをローカルで行うことはあまり安全ではありません。

あなたの状況については、リスクとコストの問題だと言います。あなたのアプリケーションがハッキングされ、購入をバイパスしている顧客と追加のセキュリティを導入するコストとは、何が危険なのでしょうか。あなたのアプリケーションが10万回以上ダウンロードされている場合は、かなりのリスクがあります。 100万回以上の場合、高いリスクがあります。わずか数千の場合、海賊行為はおそらくあなたのアプリを見落としてしまうでしょう。追加されたセキュリティを選択する場合は、サーバーを起動して実行し、次にAppとサーバーに必要なすべてのコードとハンドシェイクを追加する必要があります。すべての時間とお金が必要になります。特にあなたのアプリケーションの生活の中でサーバーの支払いに。