Pourquoi est-il important de définir le développeur de la charge utile dans l'application de facturation?

Question

J'utilise la version 3 de l'application de facturation de l'API. J'ai un seul, a réussi, non-consommation de l'élément. Je n'ai pas publié cette fonctionnalité dans mon application, de sorte que je voulez décider sur l'achat de la charge utile le contenu avant tout achat.

De "Meilleures Pratiques De Sécurité":

Définir le développeur de la charge utile de la chaîne lors de la prise des demandes d'achat

Dans le cas de l'application de Facturation de la Version 3 de l'API, vous pouvez inclure un " développeur charge' de la chaîne de jeton lors de l'envoi de votre demande d'achat pour Google Jouer. En général, ce est utilisé pour transmettre une chaîne de jeton unique identifie cette demande d'achat. Si vous spécifiez une valeur de chaîne, Google Play renvoie cette chaîne avec l'achat de réponse. Par la suite, lorsque vous effectuez des requêtes au sujet de ce rachat, Google Play retourne cette chaîne avec les détails de l'achat.

Vous devez passer dans une chaîne de jeton qui permet à votre application de identifier l'utilisateur qui a effectué l'achat, de sorte que vous pouvez vérifier par la suite que c'est un achat légitime par l'utilisateur. Pour les consommables, vous pouvez utiliser généré de façon aléatoire une chaîne de caractères, mais pour les non-consommables vous devez utiliser une chaîne de caractères qui identifie de manière unique l'utilisateur.

Lorsque vous obtenez la réponse à partir de Google Play, assurez-vous de vérifier que le développeur de la charge utile de la chaîne correspond au jeton que vous avez envoyé auparavant, avec la demande d'achat. Comme plus de sécurité précaution, vous devriez effectuer la vérification sur votre propre sécurisé serveur.

A tort ou à raison, j'ai décidé de ne pas prendre la précaution de sécurité" de la configuration d'un serveur pour effectuer l'achat de vérification. Et je n'ai pas de magasin de mon propre record de l'achat -- j'ai toujours appeler à la facturation de l'API. Donc, est-il vraiment aucune raison pour moi de faire cette charge de la vérification? La vérification de l'API en elle-même certainement vérifie l'identité d'un utilisateur avant de signaler un article acheté, et si un attaquant a compromis un dispositif (soit l'application ou le google play API), je ne vois pas l'avantage de faire une vérification supplémentaire de l'utilisateur d'identifier sur l'appareil à un endroit où il peut être facilement contourné. Ou est-il une raison pour faire ce que je ne pense pas?

Answer 1

Si vous ne gardez pas un record, il n'y a aucun moyen de vérifier que ce que vous obtenez est ce que vous avez envoyé. Donc, si vous ajouter quelque chose pour le développeur de charge utile, vous pouvez croire que c'est légitime (ce qui est une hypothèse raisonnable, si la signature vérifie), ou de ne pas faire confiance complètement et ne l'utiliser qu'une référence, mais pas pour la validation de l'état des licences, etc. Si vous stockez l'email de l'utilisateur, par exemple, vous pouvez utiliser la valeur plutôt que de leur demander de le saisir à nouveau, ce qui est légèrement plus conviviale, mais votre application ne pas se briser si elle n'est pas là.

Personnellement, je pense que cet ensemble de "meilleures pratiques" de la partie est déroutant et il essaie de vous faire faire un travail que l'API devrait vraiment être fait. Depuis l'achat est lié à un compte Google, et le Play Store évidemment enregistre cette information, ils devraient vous donner ce dans les détails de l'achat. Obtention d'une bonne ID utilisateur nécessite des autorisations supplémentaires que vous ne devriez pas avoir à ajouter pour couvrir les carences de l'IAB et de l'API.

Donc, en résumé, sauf si vous avez votre propre serveur spécial sur la logique, il suffit de ne pas utiliser le développeur de la charge utile. Vous devriez être OK, tant que l'IAB v3 de l'API travaille (ce qui est, malheureusement, tout à fait un gros "si", mais à ce point).

Answer 2

Vous devez passer dans une chaîne de jeton qui permet à votre application d'identifier l'utilisateur qui a effectué l'achat...

Si votre application dispose de sa propre connexion de l'utilisateur et de l'identité, qui est différent de ce que les comptes Google le téléphone est connecté, vous devez utiliser le développeur de la charge utile de joindre l'achat de l'un de vos comptes qui ont fait l'achat. Sinon, quelqu'un pourrait changer de compte dans votre application, et d'obtenir le bénéfice de la acheté des trucs.

par exemple

Supposons que notre application a la connexion de l'utilisateur a et utilisateur b. Et le téléphone Android de google compte est X.

1. userA, des journaux dans notre application et les achats de membre à vie. Les détails de l'achat, sont stockées sous compte google X.
2. l'utilisateur se déconnecte, et l'utilisateur b ouvre une session sur notre application. Maintenant, userB obtient également les avantages de l'adhésion à vie, comme android de google compte est toujours X.

Pour éviter de tels abus, nous nous attacherons un achat à un compte. Dans l'exemple ci-dessus, nous allons mettre en développeur de charge utile en tant que "user" lorsque l'utilisateur est d'en faire l'achat. Ainsi, lorsque l'utilisateur b se connecte, la charge ne correspond pas à signé à l'utilisateur (utilisateur b), et nous ferons abstraction de l'achat. Ainsi, l'utilisateur b ne peut pas obtenir des avantages d'un achat effectué par l'utilisateur.

Answer 3

Il y a aussi une autre approche pour le développeur en charge de la manipulation. Comme Nikolaï Elenkov dit que c'est trop compliqué pour exiger l'ID utilisateur et le réglage des permissions supplémentaires pour le profil de l'utilisateur de votre application, donc ce n'est pas une bonne approche. Alors voyons voir ce que Google dit dans la dernière version de TrivialDrive exemple d'application dans l'Application de Facturation v3 échantillons:

• AVERTISSEMENT: Localement, la génération d'une chaîne de caractères aléatoires lors du démarrage de l'achat et de la en vérifiant qu'il pourrait sembler comme une bonne approche, mais cela ne fonctionne pas dans le cas où l'utilisateur achète un article sur un appareil, puis utilise votre application sur un dispositif différent, parce que sur l'autre appareil, vous n'aurez pas accès à la chaîne de caractères aléatoires d'origine que vous avez généré.

Si la chaîne de caractères aléatoires n'est pas une bonne idée si vous allez vérifier l'article acheté sur un autre appareil, mais encore ils ne disent pas ce n'est pas une bonne idée de vérifier l'achat de réponse. Je dirais utilisation développeur de la charge utile pour la vérification de l'achat par l'envoi d'un hasard chaîne unique, enregistrer dans préférences/base de données et sur l'achat et la réponse de ce développeur de charge utile. Comme pour l'interrogation de l'inventaire (achats in-app) sur l'Activité de la start - n'est pas la peine de vérifier développeur de charge utile, puisque cela pourrait se produire sur un autre appareil lorsque vous n'avez pas d'aléatoire unique chaîne de caractères stockée. C'est la façon dont je le vois.

Answer 4

J'ai eu du mal avec celui-ci. Depuis un compte Google Play ne peut posséder qu'un seul de toute "réussi", mais qui peut avoir plusieurs appareils (j'en ai trois), le commentaire ci-dessus de quelqu'un que vous vendez un "par" l'appareil " ne fonctionne pas... ils seraient capables de le mettre sur leur premier appareil, et pas d'autres jamais... Si vous achetez une prime de mise à niveau, il devrait fonctionner sur tous les téléphones/tablettes.

Je méprise la notion de l'obtention de l'adresse électronique de l'utilisateur, mais j'ai vraiment trouvé aucun autre méthode fiable. Donc je prends le 1er compte que les matches "google.com" dans la liste des comptes (oui, une autorisation d'ajouter à votre manifeste), puis immédiatement de hachage de sorte qu'il n'est plus utilisable comme une adresse e-mail, mais ne fournissent un "assez unique jeton". C'est ce que j'ai envoyé en tant que Développeur de la Charge utile. Comme la plupart des gens activer leur appareil avec leur Google Play id, il y a un bon coup à tous les trois dispositifs obtiendrez la même jeton (en utilisant le même algorithme de hachage sur chaque appareil).

Il fonctionne même sur KitKat avec plusieurs "utilisateurs". (Mon identifiant de développeur est sur un utilisateur, mon test id sur l'autre, et chaque utilisateur dans son propre bac à sable).

Je l'ai testé sur six appareils avec un total de 3 utilisateurs et les utilisateurs des appareils ont renvoyé le même hash, et les différents utilisateurs, toutes ont des tables de hachage, satisfaisant les lignes directrices.

À aucun moment, suis-je le stockage de l'adresse électronique de l'utilisateur, il est passé directement depuis le code pour obtenir les noms de compte de la fonction de hachage, et seul le hachage est enregistré dans le tas.

Il y a probablement encore une meilleure solution qui respecte la vie privée des utilisateurs encore plus, mais jusqu'à présent, je n'ai pas trouvé. Je vais mettre une description très claire de la façon dont j'utilise les utilisateurs de l'adresse e-Mail dans ma politique de confidentialité une fois que l'application est publiée.