hack - (iOS+StoreKit) ¿Puedo detectar cuando estoy en el arenero?
in app purchase ios 11 (3)
Tengo compras en la aplicación funcionando bien, y voy por la ruta de validación del servidor. El servidor necesita saber si estoy en la zona de pruebas o no, así que por ahora solo le envío un parámetro "& sandbox = 1". Por supuesto, cuando la versión completa de la aplicación esté fuera, no enviaré este parámetro.
Prefiero no tener este código en mi aplicación, ya que eso hará que las pruebas sean difíciles en el futuro, y es una cosa más (importante) que recordar antes de enviar las compilaciones a Apple.
¿Hay alguna forma de que le pregunte a StoreKit si estoy en el entorno aislado para poder determinar si debo enviar este parámetro a mi servidor? Alternativamente, ¿existe alguna otra práctica recomendada para manejar la validación del servidor?
Pensando más en esto, ¿debería simplemente hacer que el servidor verifique primero el sistema en vivo y luego el sandbox? Si las identificaciones de Apple se segregan entre los sistemas de caja fuerte y de arena, entonces no haría ningún daño.
Gracias.
Siempre verifique su recibo primero con la URL de producción; proceda a verificar con la URL de sandbox si recibes un código de estado 21007.
Desafortunadamente, la nota técnica no menciona que esto solo es válido para las suscripciones de renovación automática.
Como se menciona en la tabla 7-1 de la Guía de programación de compras en la aplicación :
Importante Los códigos de estado distintos de cero se aplican aquí solo cuando se recupera información sobre una suscripción auto-renovable. No utilice estos códigos de estado cuando pruebe las respuestas para otros tipos de productos.
Para las suscripciones no renovadas, el servidor de producción no devuelve un código de estado, sino un recibo adecuado.
En caso de que se vea obligado a utilizar la renovación de su propia lógica de caducidad de suscripción, una posible solución es enviar la versión de su aplicación a su servidor y hacer un seguimiento de las versiones que se están desarrollando en este momento, por lo que puede redirigirlas. al servidor sandbox.itunes para verificar los recibos cuando corresponda, e imitar el tiempo de expiración de una suscripción (como hace sandbox.itunes para la renovación automática) para el desarrollo en su servidor.
Después de un poco de excavación, encontré esto en la nota técnica TN2259 de Apple:
¿Cómo verifico mi recibo (iOS)?
Siempre verifique su recibo primero con la URL de producción; proceda a verificar con la URL de sandbox si recibes un código de estado 21007. Seguir este enfoque garantiza que no tenga que cambiar de URL mientras su aplicación se está probando o revisando en el recinto de seguridad o está en vivo en la App Store.
Así que parece que debería quitar el parámetro &sandbox completamente y solo hacer eso. Realmente tuve que buscar esta respuesta, ¡así que la estoy publicando aquí con la esperanza de que alguien más la encuentre!
Encontré ese mismo problema, donde mi aplicación fue rechazada debido a que la versión de "producción" de mi aplicación que presenté estaba codificada para conectarse a un script PHP en mi servidor que valida los recibos con el servidor de AppStore real (mientras que mi desarrollo apunta a otro script PHP que valida los recibos con el servidor sandbox). Sin embargo, después de algunos intercambios con los ingenieros de Apple, descubrí que utilizan cuentas de usuario de espacio aislado para probar las aplicaciones enviadas, lo que explica por qué recibieron un error.
En lugar de construir condicionalmente mi aplicación para que apunte a un script u otro, usaré un solo script que pruebe el servidor de producción primero y luego vuelva al servidor de sandbox si recibe el código de estado 21007, ¡como se explicó anteriormente!
¡Muchas gracias!