la valeur d'écriture du trousseau iOS génère le code d'erreur -34018
J'ai une application iOS qui stocke des informations sensibles dans le trousseau . Lors de l'écriture de valeurs dans le trousseau, le code d'erreur -34018 s'affiche.
J'utilise actuellement la classe iOS KeyChainItemWrapper iOS.
Les deux lignes de code suivantes reçoivent le même code d'erreur.
OSStatus res1 = SecItemCopyMatching((__bridge CFDictionaryRef)genericPasswordQuery, (CFTypeRef *)&attributes);
OSStatus res = SecItemUpdate((__bridge CFDictionaryRef)updateItem, (__bridge CFDictionaryRef)tempCheck);
Ce problème ne se produit pas à chaque fois, mais par intermittence. Une fois que j'ai eu cette erreur, je ne suis plus en mesure d'écrire des valeurs dans le trousseau.
J'ai imprimé la description de l'erreur comme suit:
NSError *error = [NSError errorWithDomain:NSOSStatusErrorDomain code:res userInfo:nil];
et voici ce que l'erreur affiche:
Error: Error Domain=NSOSStatusErrorDomain Code=-34018 "The operation couldn’t be completed. (OSStatus error -34018.)"
On dirait que c'est un bogue dans Keychain, qui n'apparaît que lorsque vous lancez votre application à partir de xcode. Voir ici: https://github.com/soffes/sskeychain/issues/52
Nous avons beaucoup débogué et il semble être un problème d’accès au trousseau quand l'application est lancée à partir de l'arrière-plan. Cela se produit uniquement avec le débogueur (lorsqu’il est lancé à partir de Xcode). Nous pensons que le problème pourrait être lié dans notre cas au débogueur maintenant en vie l'application même s'il devait être tué par l'OS. Nous avons en fait essayé de lancer le app puis placez-le en arrière-plan et lancez de nombreuses autres applications à occuper RAM. Avec le débogueur, le problème est survenu lors de la reprise de l'application à partir du fichier sans le débogueur, ce n’est pas le cas (nous avons exécuté au moins 10 tests chacun).
Si quelqu'un veut revenir ici avec cette erreur et XCode8 avec iOS10, vous devez probablement activer KeyChain Share dans l'onglet Capabilities:
Comme d'autres l'ont mentionné, il s'agit d'un bogue du trousseau, dont Apple est au courant depuis au moins la mi-2015.
Le 22 mars 2016, Apple a toutefois déclaré:
Nous pensons que ces problèmes ont été résolus dans iOS 9.3.
iOS 9.3 est sorti le 21 mars 2016.
Voir le fil: https://forums.developer.Apple.com/thread/4743
Pour citer la réponse d’un employé d’Apple:
22 mars 2016 03:28
OK, voici le dernier. Ceci est un problème complexe avec plusieurs causes possibles:
Certaines occurrences du problème sont dues à une signature d'application incorrecte. Vous pouvez facilement distinguer ce cas car le problème est reproductible à 100%.
Certaines occurrences du problème sont dues à un bogue dans la manière dont iOS prend en charge le développement d'applications (r. 23 991 853). Le débogage était compliqué par le fait qu’un autre bogue dans le système d’exploitation (r. 23 770 418) masquait son effet, ce qui signifiait que le problème ne s’apparente que lorsque l’appareil était sous pression mémoire.
Nous pensons que ces problèmes ont été résolus dans iOS 9.3.
Nous soupçonnons qu'il peut y avoir encore plus de causes de ce problème.
Par conséquent, si vous rencontrez ce problème sur une machine utilisateur (dont Xcode n’a pas parlé) et exécutant iOS 9.3 ou une version ultérieure, veuillez créer un rapport de bogue à ce sujet. Essayez d’inclure le journal système des périphériques dans votre rapport de bogue (je me rends compte que cela peut être délicat lorsqu’il s’agit de gérer les périphériques du client; une option consiste à demander au client d’installer Apple Configurator, qui lui permet d’afficher le journal système). Et si vous déposez un bogue, merci de poster votre numéro de bogue, juste pour le compte rendu.
Au nom d’Apple, je voudrais remercier tout le monde pour les efforts qu’ils ont déployés pour résoudre ce problème plutôt horrible.
Partagez et profitez
Cela m'a retenu pendant 2 heures avant que je trouve une solution rapide - redémarrez le périphérique iOS
Une citation de la discussion à http://forums.developer.Apple.com/thread/4743 ,
De l'utilisateur littledetails
Comme d'autres l'ont signalé, cette mystérieuse erreur de trousseau est plus facilement observable lors du lancement via Xcode avec le débogueur associé. Une fois que l'erreur commence à se produire, le trousseau ne semble pas se redresser indépendamment de la pression de la mémoire jusqu'à ce que le périphérique soit redémarré.
Lorsque j'ai redémarré mon périphérique, l'erreur a disparu, me permettant de poursuivre les tests. Je ne sais pas quoi faire d'autre. Dans ma situation, passer à NSUserDefaults ou à une autre solution de stockage n’était pas une possibilité.
Un moyen de résoudre ce problème avec le trousseau consiste à utiliser dispatch_async pour permettre le lancement de l'application. Cela fonctionne lorsque l'application est ouverte à partir de l'arrière-plan. Vérifiez également que vous avez le paramètre d'accessibilité kSecAttrAccessibleAfterFirstUnlock sur le trousseau.
dispatch_async(dispatch_get_main_queue(), ^{
// save/write to keychain
})
J'utilise les classes GenericKeychain d'Apple:
struct KeychainConfiguration {
static let serviceName = "MyAppService"
/*
Specifying an access group to use with `KeychainPasswordItem` instances will create items shared accross both apps.
For information on App ID prefixes, see:
https://developer.Apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/AppID.html
and:
https://developer.Apple.com/library/ios/technotes/tn2311/_index.html
*/
// static let accessGroup = "[YOUR APP ID PREFIX].com.example.Apple-samplecode.GenericKeychainShared"
/*
Not specifying an access group to use with `KeychainPasswordItem` instances
will create items specific to each app.
*/
static let accessGroup: String? = nil
}
Dans ce fichier, je spécifiais mon accessGroup personnalisé dans cette ligne static let accessGroup = "[VOTRE ID APP PREFIX] .com.example.Apple-samplecode.GenericKeychainShared"
Après être retourné à static, laissez accessGroup: String? = nil le problème avait disparu. :)
Assurez-vous que partage du trousseau must sur sous Capacités dans le projet Cible .
Dans mon cas, le fichier App_Name.entitlements a un identifiant de lot différent de celui de mon identifiant de bundle de projet. Je modifie donc l'identifiant de l'ensemble dans le fichier App_Name.entitlements à partir de mon identifiant de bundle de projet . Par exemple, supposons que votre identifiant de bundle de projet soit com.Apple.testApp, puis arriver à
- Clé ouverte du fichier Nom_Appli.entitlements Clé Trousseau Clé de groupes d'accès qui est de type Array.
- Sous item0, définissez la valeur de votre identifiant de bundle de projet, par exemple: - $ (AppIdentifierPrefix) com.Apple.testAp.
Selon la réponse de @ iCaramba. J'ai trouvé une solution de contournement:
- Arrêtez la tâche pour tuer l'application (si vous utilisez déjà l'application)
- Lancez l'application sur votre appareil manuellement. NE PAS utiliser Xcode
- Utiliser Xcode pour relancer l'application