2

对于如何创建一个在我想到的场景下运行良好的合适模型,我似乎已经走到了尽头。

场景如下;用户从 Google play 购买应用程序。在运行时,我请求用户凭据(与当前设备关联的 Google 帐户),然后我将其传输到网络服务。此时,后端服务会尝试对用户进行身份验证并确定他们是否实际购买了相关应用程序,然后才返回与请求相关的任何数据。(请记住,一般来说,任何请求,正如我们谈论的基于内容的应用程序,在运行时生命周期的任何时间点对 Web 服务的任何请求都必须始终通过上述管道)。

现在,上述情况如此具体的原因是以下原因;-我希望一切都由最终服务管理,而不是让任何 Auth 进程本地运行,因为它很容易被绕过。我的意思是,只要任何人都可以在他们的设备上反编译应用程序,检查代码,根据他们的需要重新编译它,如果设备被 root 可以完全访问任何文件,甚至可以清除与应用程序相关的任何数据只需从 android 的应用程序设置中按下“清除数据”选项......除了我上面描述的那个之外,我没有看到任何其他可行的场景。

现在说了以上所有我的问题是,谷歌似乎不喜欢谷歌播放开发者 api 和谷歌+ api 的这种特定场景。

因此,我非常感谢您就我提到的场景和解决此问题的方法提供的意见、想法和任何相关材料。

4

3 回答 3

1

使用LVLProGuard有什么问题?这些工具专门设计用于分别解决您对许可证验证和逆向工程的担忧。

而且,真的不要太担心千分之一的人可能会尝试免费获得您的付费应用程序。如果您的应用程序很好,那么无论如何您都会获得大量销售。

于 2012-07-20T05:32:21.123 回答
1

我不知道您可以使用任何此类 API。为什么不试试 LVL,它可以确保它实际上是从 Android 市场下载的?如果它是一个付费应用程序,那么用户肯定已经为此付费了。

就反编译而言,试试 Proguard。这不是 100% 完美的解决方案,但很难打破它。

现在,进入内容。如果您不希望其他人窃取您的内容,请加密并保存。您可以拥有一个非常好的加密机制来与您的 Web 服务一起使用,这将确保它非常难以破解。

于 2012-07-20T05:00:53.970 回答
0

如果我正确阅读了您的建议,那听起来像是严重侵犯了您的用户隐私,并且肯定违反了 Google 的 ToS。为什么你的用户会给你他们的私人凭证?它们不应该提供给任何人,那么他们为什么要信任您或您的系统呢?如果您被黑客入侵并且凭据被盗,您也将承担责任。

于 2013-06-25T08:20:41.337 回答