Correlación de usuarios de Google Checkout para respuestas de licencias de Android

Question

que estoy usando licencias de Android como se describe aquí:

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

(... para comprobar que mis clientes para mi aplicación Android en realidad han pagado por la aplicación.) Mi aplicación tiene un componente de servidor en la web, y para mayor seguridad estoy haciendo la validación de la licencia en este servidor.

Todo funciona bien. Ahora, a mi problema. Dado que cada nuevo usuario ata recursos en mi servidor central, en realidad soy un poco reacio a tener usuarios que no pagan. He visto algunas pruebas de que los usuarios siguen usando la aplicación después de haber obtenido un reembolso (por el período de gracia normal de 15 minutos).

Para controlar este comportamiento, sería genial si hubiera alguna forma de asignar el pago de los usuarios en Google Checkout a los usuarios reales de mi sistema. es posible?

El ResponseData que recibo del servidor de la licencia de Android contiene un campo llamado "userId", pero esto no parece corresponderse con ninguna información en Google Checkout. (Consulte http://www.androidadb.com/source/skylight1-read-only/GoogleLVL/src/com/android/vending/licensing/ResponseData.java.html para obtener la definición de ResponseData).

¿Es posible determinar qué pago en Checkout se asigna a qué aplicación de instalación?

Answer 1

Como actualmente lo entiendo, el userId está ofuscado incluso por aplicación, de modo que puede identificar de manera única a los usuarios por aplicación pero no figura qué usuario es ni si el mismo usuario compró otra aplicación.

Pero no estoy seguro de que realmente necesite identificar a estos clientes según userId. Si tiene un servidor funcionando de todos modos, la mejor manera de proteger su aplicación es hacer que su servidor verifique la licencia.

1. App -> Servidor: Dame un nuevo nonce
2. servidor -> Aplicación: Aquí es un nonce aleatoria segura
3. App -> Servicio de Licencia: Hora de licencia de usuario con este nonce aleatoria segura
4. Servicio de licencia -> Aplicación: respuesta de licencia firmada incluyendo repetición de nonce
5. Aplicación -> Servidor: verificar firma de licencia con clave secreta (solo en el servidor)
6. Servidor -> Aplicación: rechazar, o proporcionar token aleatorio para acceder, etc.

En este caso, no autenticará a los usuarios aunque se equivoquen con su código de comprobación LVL.

Sin embargo, por supuesto puede presentar vulnerabilidades después del paso 6 si no observa su paso. Sin embargo, si usted está actualmente utilizando el código de LVL estándar y comprobación de la licencia del lado de la aplicación con la clave secreta almacenada en su aplicación, cambiando a un mecanismo como se esbozó más arriba sería un enorme mejora (incluso hay un script para eliminar LVL norma verificando el código de las aplicaciones).