Asignación de usuarios de Google Checkout a Android Respuestas de licencias
Estoy usando la Licencia de Android como se describe aquí:
Http://developer.android.com/guide/market/licensing/index.html
(… para verificar que mis clientes de mi aplicación android han pagado la aplicación). Mi aplicación tiene un componente de servidor en la web y, para mayor seguridad, estoy haciendo la validación de licencia en este servidor.
Todo funciona bien. Ahora, a mi problema. Dado que cada nuevo usuario vincula los recursos en mi servidor central, en realidad estoy 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 frenar este comportamiento, sería genial si hubiera alguna forma de asignar el pago de los usuarios de Google Checkout, a los usuarios reales de mi sistema. es posible?
El ResponseData que recibo del servidor de licencias android contiene un campo denominado "userId", pero no parece corresponder a ninguna información de Google Checkout. (Consulte http://www.androidadb.com/source/skylight1-read-only/GoogleLVL/src/com/android/vending/licensing/ResponseData.java.html para la definición de ResponseData.)
¿Es posible determinar qué pago en los mapas de Checkout a qué instalación de la aplicación?
Como lo entiendo actualmente, el userId se obscurece incluso en una base de por-aplicación tal que usted puede identificar únicamente a usuarios por la aplicación pero no figura qué usuario es ni si el mismo usuario compró otra aplicación.
Pero no estoy seguro de que realmente necesita identificar a estos clientes basados en userId . Si tiene un servidor funcionando de todos modos, la mejor manera de proteger su aplicación es hacer que su servidor compruebe la licencia.
- Aplicación -> Servidor: Give me a new nonce
- Servidor -> Aplicación: Aquí está un seguro nonce aleatorio
- Aplicación -> Servicio de licencia: compruebe la licencia de usuario con este seguro nonce aleatorio
- Servicio de licencia -> Aplicación: Firma de respuesta de licencia incluyendo repetición de nonce
- Aplicación -> Servidor: Comprobar la firma de la licencia con clave secreta (sólo en el servidor)
- Servidor -> Aplicación: Rechazar o proporcionar un token aleatorio para el acceso, etc.
En este escenario, no autenticará a los usuarios incluso si se meten con su código de verificación LVL.
Sin embargo, puede introducir vulnerabilidades después del paso 6 si no observa su paso. Aún así, si actualmente utiliza el código LVL estándar y la licencia de la aplicación con la clave secreta almacenada en su aplicación, cambiar a un mecanismo como se ha esbozado anteriormente sería una gran mejora (incluso hay un script para eliminar el código de verificación LVL estándar Desde aplicaciones).