android - play - google maps api key gratis

¿Qué usar como carga útil del desarrollador en las API de facturación en la aplicación de Google?

Question

La clase de capacitación para vender productos integrados en la aplicación en Android sugiere utilizar una carga útil al realizar una solicitud de compra:

El quinto argumento contiene una cadena de ''carga útil del desarrollador'' que puede usar para enviar información suplementaria sobre un pedido (puede ser una cadena vacía). Normalmente, esto se utiliza para pasar un token de cadena que identifica de forma única esta solicitud de compra. Si especifica un valor de cadena, Google Play devuelve esta cadena junto con la respuesta de compra. Posteriormente, cuando realiza consultas sobre esta compra, Google Play devuelve esta cadena junto con los detalles de la compra.

Recomendación de seguridad: es una buena práctica enviar una cadena que ayude a su aplicación a identificar al usuario que realizó la compra, para que luego pueda verificar que esta sea una compra legítima por parte de ese usuario. Para los artículos consumibles, puede usar una cadena generada aleatoriamente, pero para los artículos no consumibles debe usar una cadena que identifica al usuario de manera única.

La página de Implementación de compra de IAB tiene una recomendación similar, con la sugerencia adicional de que el valor de la carga útil debe verificarse en su propio servidor seguro:

Recomendación de seguridad: cuando envíe una solicitud de compra, cree un token de cadena que identifique de forma exclusiva esta solicitud de compra e incluya este token en la carga de desarrollador. Puede usar una cadena generada aleatoriamente como token. Cuando reciba la respuesta de compra de Google Play, asegúrese de verificar la firma de datos devueltos, el Id. De pedido y la Cadena de carga de desarrollador. Para mayor seguridad, debe realizar la verificación en su propio servidor seguro. Asegúrese de verificar que orderId es un valor único que no ha procesado previamente, y developerPayload String coincide con el token que envió previamente con la solicitud de compra.

Al observar el código fuente de la aplicación Trivial Drive que Google está utilizando para demostrar la API, encuentro esta advertencia:

* WARNING: Locally generating a random string when starting a purchase and
* verifying it here might seem like a good approach, but this will fail in the
* case where the user purchases an item on one device and then uses your app on
* a different device, because on the other device you will not have access to the
* random string you originally generated.
*
* So a good developer payload has these characteristics:
*
* 1. If two different users purchase an item, the payload is different between them,
* so that one user''s purchase can''t be replayed to another user.
*
* 2. The payload must be such that you can verify it even when the app wasn''t the
* one who initiated the purchase flow (so that items purchased by the user on
* one device work on other devices owned by the user).
*
* Using your own server to store and verify developer payloads across app
* installations is recommended.

Entonces, de todos estos mensajes, parece una mala idea usar un número / cadena aleatorio para la carga útil. Además, después de leer la última advertencia, parece una mala idea pasar la identificación del dispositivo como la carga útil, ya que será diferente para el mismo usuario en diferentes dispositivos. Entonces, ¿qué debería usarse para la carga útil del desarrollador?

Mi aplicación proporciona una funcionalidad local a la que puede acceder el usuario sin tener que iniciar sesión en ningún servicio. Por lo tanto, no existe el concepto de un "usuario" y tampoco existe un componente del lado del servidor. La solicitud de compra en la aplicación es para una actualización que elimina anuncios de la aplicación. ¿Tiene sentido que una aplicación como esta haga uso de la función de carga útil, o me conviene usar una cadena vacía y dejarla propensa a reproducir ataques?

Answer 1

Mi conocimiento con la compra de InApp proviene de la biblioteca anterior de v2. No he trabajado con la versión más nueva de v3. Sin embargo, espero que aún pueda ser útil.

Sí, usar la carga útil del desarrollador como una característica de seguridad adicional definitivamente ayudará, sin embargo, si debes o no es probablemente más subjetivo que un dilema objetivo. En mi caso, mi cliente ya tenía un servidor en la mezcla, ya que los clientes tenían que descargar 200 MB de archivos después de una compra en la aplicación. Usamos la carga útil del desarrollador para almacenar información sobre el archivo autorizado para descargar. Esta información fue fundamental al decirle a la aplicación cómo procesar los archivos descargados.

Seguimos brindando seguridad adicional anulando el verifyPurchase() local verifyPurchase() con una llamada al servidor. IE, suministrando nuestra propia cuenta para verificar. Hacer eso localmente no es muy seguro.

En cuanto a su situación, yo digo que es una cuestión de riesgo versus costo. ¿Cuál es el riesgo de que su aplicación sea pirateada y que los clientes pasen por alto las compras frente al costo de implementar la seguridad adicional? Si su aplicación se está descargando más de 100.000 veces, entonces tiene una cantidad considerable de riesgo. Si hay más de 1 millón de veces, entonces hay un alto riesgo. Si solo unos pocos miles, la piratería probablemente pasará por alto su aplicación. Si elige la seguridad añadida, debe poner en funcionamiento un servidor y luego agregar todo el código y el protocolo de enlace necesarios para la aplicación y el servidor. Todo lo cual requerirá tiempo y dinero. Especialmente en el pago de un servidor durante la vida de su aplicación.