映射用户从谷歌结帐到Android授权响应 [英] Mapping users from Google Checkout to Android Licensing responses

查看:167
本文介绍了映射用户从谷歌结帐到Android授权响应的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我使用Android的授权如下所述:

I am using Android Licensing as described here:

http://developer.android.com/guide/market/licensing/ index.html的

(...来验证我的客户对我的Andr​​oid应用程序实际上所许的应用程序。)我的应用程序已经在网络上的服务器组件,并为额外的安全我做的许可验证这台服务器上。

(...to verify that my customers for my android app have actually payed for the app.) My app has a server component on the web, and for extra safety I'm doing the license validation on this server.

这一切都工作好。现在,我的问题。由于每个新用户我的中央服务器上,占用了资源,我其实是那种不愿让非付费用户。我所看到的用户继续使用该应用程序后,已经得到(每正常15分钟的宽限期)退款的一些证据。

It all works okay. Now, to my problem. Since each new user ties up resources on my central server, I'm actually kind of reluctant to have non-paying users. I have seen some evidence of users continuing to use the app after having gotten a refund (per the normal 15-minute grace period).

要遏制这种行为,这将是巨大的,如果有一些方法来映射在谷歌结帐在我的系统支付的用户,实际用户。这可能吗?

To curb this behavior, it would be great if there was some way to map the payment of users at Google Checkout, to actual users in my system. Is this possible?

这是我从Android的许可证服务器接收ResponseData包含一个名为用户id字段,但是这似乎并不符合在谷歌Checkout的任何信息。 (请参阅http://www.androidadb.com/source/skylight1-read-only/GoogleLVL/src/com/android/vending/licensing/ResponseData.java.html为ResponseData的定义。)

The ResponseData that I receive from the android license server contains a field called "userId", but this doesn't seem to correspond to any information in Google Checkout. (See http://www.androidadb.com/source/skylight1-read-only/GoogleLVL/src/com/android/vending/licensing/ResponseData.java.html for the definition of ResponseData.)

是否有可能以确定哪些付款结帐映射到哪些应用安装?

Is it possible to determine which payment in Checkout maps to which app installation?

推荐答案

据我目前了解,用户id 进行模糊处理,即使在每个应用程序的基础,这样你可以唯一地标识每个应用程序的用户,但不明白它是用户也不相同用户是否购买其他应用程序。

As I currently understand it, the userId is obfuscated even on a per-app basis such that you can uniquely identify users per app but not figure which user it is nor whether the same user bought another app.

但我不知道你真的需要确定这些客户根据用户id 。如果你有反正运行服务器,以保护您的应用程序的最佳方式是让你的服务器检查许可证。

But I'm not sure you really need to identify these customers based on userId. If you have a server running anyway, the best way to protect your app is to have your server check the licence.


  1. 应用程序 - >服务器:给我一个新的随机数

  2. 服务器 - >应用程序:这是一个安全的随机现时

  3. 应用程序 - >许可证服务:检查用户许可证与此安全随机现时

  4. 许可证服务 - >应用:包括现时的重复签名的授权响应

  5. 应用程序 - >服务器:检查密钥(仅在服务器上)许可证签名

  6. 服务器 - >应用:拒绝,或访问提供随机令牌等

在这种情况下,你会不会验证用户身份,即使他们惹你LVL检查code。

In this scenario, you won't authenticate users even if they mess with your LVL checking code.

但是,您可能当然引进第6步之后的漏洞,如果你不看你的脚步。不过,如果你正在使用标准的LVL code和App端许可证检查与存储在您的应用程序密钥,改变如上勾勒将是一个的巨大的改进机制(甚至有一个脚本来移除应用标准LVL检查code)。

However, you may of course introduce vulnerabilities after step 6 if you don't watch your step. Still, if you're currently using the standard LVL code and App-side licence check with the secret key stored in your app, changing to a mechanism as sketched above would be a huge improvement (there's even a script to remove standard LVL checking code from apps).

这篇关于映射用户从谷歌结帐到Android授权响应的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆