2011-11-03 20 views
12

Estoy trabajando para actualizar un iPhone application con un pequeño cambio en su configuración predeterminada. Ha pasado un tiempo desde la última vez que lo construí, así que actualicé Xcode a 4.2 e incluí iOS 5 en las últimas compilaciones.iOS Keychain SecItemAdd returns -25243

Cuando voy a probar en el dispositivo, me sale el siguiente error de aserción:

2011-11-02 20:57:18.869 RoseBandwidth[903:707] Tried to add item, got result: -25243 
2011-11-02 20:57:18.870 RoseBandwidth[903:707] *** Assertion failure in -[KeychainItemWrapper writeToKeychain], /Users/tim/code/RoseBandwidth/Classes/KeychainItemWrapper.m:312 
2011-11-02 20:57:18.872 RoseBandwidth[903:707] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Couldn't add the Keychain Item.' 

estoy usando la implementación de la clase KeychainItemWrapper de Apple de GenericKeychain project. Vale la pena señalar que este error solo aparece en el dispositivo, no en el simulador (y soy consciente de las diferencias de restricción del grupo de acceso entre las plataformas, pero normalmente pensé que eso causaba problemas en el simulador, no en el hardware real).

¿Por qué volvería a recibir este error? No he tocado nada relevante para las partes relacionadas con la llave de la aplicación; almacena y recupera datos exactamente como solía hacerlo.

Respuesta

18

De acuerdo, no pude conseguir que tu proyecto fuera compilado, pero a partir de How to share keychain data between iOS applications creo que es posible que desee verificar el archivo de sus derechos. Al menos en el proyecto github no tienes nada especificado en los Grupos de Acceso a Llaveros.

+0

Te hubiera votado más de una vez si pudiera, esa respuesta fue francamente mágica. Resulta que perdí mi archivo de derechos en algún momento, así que volver a habilitarlos (y jugar con los perfiles de aprovisionamiento por un tiempo) solucionó este problema. ¡Gracias! – Tim

9

Para futuros buscadores que terminan aquí, se está ejecutando en el simulador otra posible causa del error -25243 (que significa No access control, BTW).

Mi mejor teoría es que el perfil de provisión de la aplicación (o la firma del mismo) es la forma en que la aplicación sabe cuál es su semilla del paquete. Y la semilla del paquete debe ser parte del nombre del grupo de acceso de su llavero. Pero las aplicaciones que se ejecutan en el simulador no se firman, y por lo tanto, faltan (¿o diferente?) Una semilla que usted especificó keychain-access-group.

O algo así. Todo está tan mal documentado, es difícil saber qué es qué. Simplemente intente ejecutarlo en un dispositivo y vea si eso ayuda.

+0

Este es un buen punto, gracias por subirlo. Noto en mi pregunta original que estoy usando el [KeychainItemWrapper] de Apple (https://developer.apple.com/library/ios/#samplecode/GenericKeychain/Listings/Classes_KeychainItemWrapper_m.html#//apple_ref/doc/uid/DTS40007797 -Classes_KeychainItemWrapper_m-DontLinkElementID_10) class, que incluye una cláusula compiladora '# if' para verificar si la aplicación se está ejecutando en el simulador. Las personas que no usan esa envoltura deben tomar precauciones. – Tim

+0

Gracias, jemmons. Me ayudó mucho – makaron

3

Recibo el mismo error de vez en cuando en el simulador, incluso si no toqué el código. Un reinicio del simulador resuelve el problema para mí.

Ver esta pregunta/respuesta cómo restablecer el simulador: https://stackoverflow.com/a/3442326

+0

+1: Bueno, esto es molesto ... Tengo el mismo problema con el simulador (y un reinicio seguro que lo arregla), pero (creo) no está sucediendo en el dispositivo. ¿Alguna vez ves esto al azar en el dispositivo? –

+0

No, hasta ahora no he visto este error en un dispositivo. – ToniTornado

1

Como otros han señalado, en el dispositivo construye error -25243 a menudo es causada por intentar acceder a un grupo de acceso llavero que usted no tiene permisos para. (Falta en su archivo Entitlements.plist o su perfil de aprovisionamiento).

Pero en el simulador puede haber otra causa. El simulador no es compatible con los grupos de acceso de llavero en todo, por lo que si establece la propiedad kSecAttrAccessGroup en un elemento de llavero e intenta escribirlo, obtendrá este código de error -25243.

FYI, código GenericKeychain muestra de Apple tiene este comentario:

// Ignore the access group if running on the iPhone simulator. 
// 
// Apps that are built for the simulator aren't signed, so there's no keychain access group 
// for the simulator to check. This means that all apps can see all keychain items when run 
// on the simulator. 
// 
// If a SecItem contains an access group attribute, SecItemAdd and SecItemUpdate on the 
// simulator will return -25243 (errSecNoAccessForItem). 
4

Para aquellos de ustedes conseguir este error y tratando de lograr "compartido Cadena clave de acceso" entre dos aplicaciones:

Es necesario crear un ID de aplicación para su aplicación con el mismo ID de equipo que seleccionó cuando activó por primera vez "Acceso compartido a llavero" en "Capacidades".Crear su ID de aplicación aquí:. Apple Member Center

Después de que usted necesita para crear el aprovisionamiento perfil de ese ID de aplicación y descargarla en el ordenador (doble clic en él para instalar en X-Code)

Asumo que ya sabe que necesita "ID de la aplicación del prefijo" para acceder a un llavero, pero para aquellos que no lo saben: "ID de la aplicación del prefijo" es el identificador único del texto asociada con su cuenta de desarrollador de Apple: enter image description here

para acceder a "SharedKeychain" necesita implementarlo así antes de intentar escribir o leer desde el llavero

keychainAccessGroupName = "AB123CDE45.myKeyChainGroup":

Se puede extraer de este tutorial para obtener más información: Share Keychain between iOS apps.

Espero que ayude.

0

Esto funcionó para mí cuando utilicé un certificado de producción y un perfil de aprovisionamiento. El uso de depuración no funcionó.

0

En mi experiencia, entiendo que el valor de retorno -25243 cuando me di cuenta de que yo estaba tratando de pasar kSecMatchLimit con kSecMatchLimitOne y kSecReturnData con kCFBooleanTrue los valores de la función SecItemAdd(). Los eliminé y revisé dos veces los ID de las aplicaciones y los perfiles de aprovisionamiento, y todo está bien.

No estoy seguro de si esto es útil o no, pero en mi experiencia si va a utilizar la función SecItemAdd() para acceso compartido a llavero, esos dos parámetros no deben estar allí.

Cuestiones relacionadas