iphone - solicita - quitar contraseña llavero mac
Almacenamiento de recibos de compra en la aplicación en la aplicación Llavero (1)
Hacemos exactamente eso en nuestras aplicaciones y funciona muy bien. Es una aplicación gratuita que puede actualizar a una versión completa y almacenamos el indicador de actualización en el llavero. El indicador de actualización es una cadena arbitraria que usted elige, pero a los efectos del llavero se trata como una contraseña, es decir, el valor de kSecValueData se cifra en el llavero. Una buena ventaja de este enfoque es que si el usuario elimina la aplicación y luego la vuelve a instalar, todo se vuelve a habilitar como magia porque los elementos del llavero se almacenan por separado de la aplicación. Y es tan poco trabajo adicional sobre el almacenamiento de algo en los valores predeterminados del usuario que decidimos que valía la pena.
Aquí es cómo crear el elemento de seguridad:
NSMutableDictionary* dict = [NSMutableDictionary dictionary];
[dict setObject: (id) kSecClassGenericPassword forKey: (id) kSecClass];
[dict setObject: kYourUpgradeStateKey forKey: (id) kSecAttrService];
[dict setObject: kYourUpgradeStateValue forKey: (id) kSecValueData];
SecItemAdd ((CFDictionaryRef) dict, NULL);
Aquí es cómo encontrar el elemento de seguridad para comprobar su valor:
NSMutableDictionary* query = [NSMutableDictionary dictionary];
[query setObject: (id) kSecClassGenericPassword forKey: (id) kSecClass];
[query setObject: kYourUpgradeStateKey forKey: (id) kSecAttrService];
[query setObject: (id) kCFBooleanTrue forKey: (id) kSecReturnData];
NSData* upgradeItemData = nil;
SecItemCopyMatching ( (CFDictionaryRef) query, (CFTypeRef*) &upgradeItemData );
if ( !upgradeItemData )
{
// Disable feature
}
else
{
NSString* s = [[[NSString alloc]
initWithData: upgradeItemData
encoding: NSUTF8StringEncoding] autorelease];
if ( [s isEqualToString: kYourUpgradeStateValue] )
{
// Enable feature
}
}
Si upgradeItemData es nil, entonces la clave no existe, por lo que puede suponer que la actualización no está allí o, lo que hacemos, se coloca en un valor que significa que no se actualizó.
Actualizar
Se agregó kSecReturnData (Gracias @Luis por señalarlo)
Nunca he implementado In App Purchase antes, así que usé el contenedor MKStoreKit y tengo una implementación que funciona. MKStoreKit conserva todos los recibos en UserDefaults .plist como BOOL, por lo que es muy simple para los piratas distribuir las compras en la aplicación en un estado "craqueado". Una vez que se realiza la primera compra, se puede distribuir el paquete y se puede recrear .plist para habilitar los desbloqueos de IAP.
Me gustaría extender MKStoreKit para crear los datos de validación de compra en aplicación en el llavero de iOS. ¿Existe algún inconveniente o una posible razón para que esto falle para los usuarios que pagan, que sea poco confiable o alguna otra razón por la que sería una mala idea general hacer esto? Entiendo que la piratería es inevitable, y definitivamente no quiero alejar a los usuarios que pagan, pero creo que la lista de errores predeterminados por el usuario es demasiado fácil de evitar.
En mi caso, una cadena simple se colocará en el llavero cuando se realice la compra. De esa manera, si el binario se distribuye, los desbloqueables aún no están habilitados. Claro, sería posible encontrar una solución alternativa, pero tomaría un poco más de esfuerzo y saber cómo encontrar el indicador VERDADERO / FALSO y hacer que siempre devuelva el valor correcto. A través de la ofuscación, incluso podría hacer que sea un poco más difícil rastrearlo.
Gracias por todas sus ideas y agradezco las respuestas que evitan las inevitables respuestas de piratería, trato con él. Estoy más interesado en las viabilidades técnicas de esta solución.