Google In-App Billing APIの開発者ペイロードとして何を使用しますか？
Androidでアプリ内商品を販売するためのトレーニングクラス は、購入リクエストを行うときにペイロードを使用することを提案しています。
5番目の引数には、注文に関する補足情報を送信するために使用できる「開発者ペイロード」文字列が含まれています（空の文字列でもかまいません）。通常、これは、この購入リクエストを一意に識別する文字列トークンを渡すために使用されます。文字列値を指定すると、GooglePlayは購入応答とともにこの文字列を返します。その後、この購入についてクエリを実行すると、GooglePlayはこの文字列を購入の詳細とともに返します。
セキュリティに関する推奨事項：アプリケーションが購入したユーザーを識別しやすくする文字列を渡すことをお勧めします。これにより、後でこれを確認できます。そのユーザーによる正当な購入です。消耗品の場合はランダムに生成された文字列を使用できますが、非消耗品の場合はユーザーを一意に識別する文字列を使用する必要があります。
IAB購入ページの実装 にも同様の推奨事項がありますが、ペイロード値を独自の安全なサーバーでチェックする必要があるという追加の提案があります。
セキュリティに関する推奨事項：購入リクエストを送信するときは、この購入リクエストを一意に識別する文字列トークンを作成し、このトークンをdeveloperPayloadに含めます。トークンとしてランダムに生成された文字列。 Google Playから購入の応答を受け取ったら、返されたデータ署名、orderId、およびdeveloperPayload文字列を必ず確認してください。セキュリティを強化するには、自分の安全なサーバーでチェックを実行する必要があります。 orderIdが以前に処理したことのない一意の値であり、developerPayload文字列が以前に購入リクエストで送信したトークンと一致することを確認してください。
GoogleがAPIのデモンストレーションに使用しているTrivialDriveアプリのソースコードを見ると、次の警告が見つかります。
* 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をペイロードとして渡すのは悪い考えのように思えます。これは、デバイスが異なる同じユーザーでは異なるためです。では、開発者のペイロードには何を使用する必要がありますか？
私のアプリは、ユーザーがサービスにサインインしなくてもアクセスできるローカル機能を提供します。したがって、「ユーザー」の概念はなく、サーバー側のコンポーネントもありません。アプリ内購入リクエストは、アプリから広告を削除するアップグレードを対象としています。このようなアプリがペイロード機能を利用することは理にかなっていますか、それとも空の文字列を使用してリプレイ攻撃を受けやすいままにしておくほうがよいでしょうか？
InAppの購入に関する私の知識は、古いv2ライブラリからのものです。私は最新のv3を使用していません。しかし、うまくいけば、私はまだ役立つことができます。
はい、追加のセキュリティ機能として開発者ペイロードを使用することは間違いなく役立ちますが、そうすべきかどうかは、おそらく客観的なジレンマよりも主観的です。私の場合、顧客はアプリ内購入後に200 MBのファイルをダウンロードする必要があるため、クライアントにはすでにサーバーが混在しています。開発者ペイロードを使用して、ダウンロードが許可されたファイルに関する情報を保存しました。この情報は、ダウンロードしたファイルの処理方法をアプリに伝える上で重要でした。
ローカルのverifyPurchase()メソッドをサーバー呼び出しでオーバーライドすることにより、セキュリティを強化しました。 IE、チェックする独自のナンスを提供します。ローカルでそれを行うことはあまり安全ではありません。
あなたの状況に関しては、私はそれがリスク対コストの問題だと言います。アプリがハッキングされ、顧客が購入をバイパスするリスクと、追加されたセキュリティを実装するコストはどのくらいですか。アプリが100,000回以上ダウンロードされている場合は、かなりのリスクがあります。 100万回を超えると、リスクが高くなります。数千の場合、著作権侵害はおそらくアプリを見落とします。追加のセキュリティを選択した場合は、サーバーを起動して実行してから、アプリとサーバーに必要なすべてのコードとハンドシェイクを追加する必要があります。これらはすべて時間とお金が必要です。特に、アプリの存続期間中にサーバーの料金を支払う場合。