Si votre application a une fonction d'enregistrement qui inclut la possibilité ou la nécessité de saisir un nouveau nom d'utilisateur et un nouveau mot de passe, vous serez probablement intéressé par l'innovation dans
iOS 12 , que j'aimerais souligner. Il s'agit d'un service qui invente de nouveaux mots de passe pour l'utilisateur, les substitue automatiquement dans les champs nécessaires et les stocke en toute sécurité dans le
trousseau .
Les mots de passe système générés automatiquement sont les plus résistants à la sélection (étant des séquences de caractères générées aléatoirement - ajustées pour les restrictions personnalisées, mais plus à ce sujet plus tard), soulagent les utilisateurs de l'application de la nécessité de créer une séquence qui leur est propre et sont configurées de manière flexible pour les besoins d'une application particulière. La prise en charge de nouvelles fonctionnalités est assez facile à fournir, cependant, non sans fonctionnalités. Mais tout d'abord.
Droits et obligations
Tout d'abord, l'application doit déclarer sa volonté d'utiliser cette fonctionnalité. Dans la liste des
capacités de la
cible correspondante
, vous devez d'abord avoir un domaine dans la liste des
domaines associés . Curieusement, l'application doit avoir un «domaine associé» afin de pouvoir utiliser les mots de passe générés et les stocker dans le «trousseau» de l'utilisateur (ces deux fonctions sont interconnectées et la génération ne peut pas être utilisée séparément du stockage).
Si l'application prend déjà en charge l'
utilisation de comptes partagés avec votre site (les «informations d'identification partagées») , cette étape est déjà en retard. Il peut également être déjà en retard et si l'application prend en charge
les liens universels ou un autre mécanisme de traitement des
«URL» externes.
Quoi qu'il en soit, après avoir ajouté cette compatibilité, l'application aura un nouveau
«droit» .
En plus de cette compatibilité plus générale, l'application devrait également avoir la «capacité»
«fournisseur d'informations d'identification de remplissage automatique» - cela permet à l'application, si l'autorisation de l'utilisateur est autorisée, d'utiliser les identifiants et les mots de passe proposés par le système. L'ajout de cette compatibilité entraînera l'apparition de l'autorisation
Autofill Credential Provider Entitlement .
Soit dit en passant, l'ajout de cette fonctionnalité et d'autres fonctionnalités n'est disponible que pour les membres du programme pour développeurs Apple .
Le profil d'approvisionnement utilisé par l'application doit également inclure les deux fonctionnalités suivantes.
Dépendances utilisées
L'ajout de la compatibilité appropriée entraînera l'apparition du
cadre AuthenticationServices dans la liste Frameworks et bibliothèques liés de la cible correspondante. Ce point a quelques caractéristiques qui méritent d'être mentionnées.
Premièrement, l'ajout automatique d'un framework associé peut ne pas «fonctionner» la première fois: lorsque je lance l'application sur un appareil réel à partir de ma copie de
«Xcode» version 10.1, l'application a immédiatement «planté» en raison du manque de «AuthenticationServices». La suppression manuelle du cadre et son ajout à la liste des composants associés ont résolu le problème.
Deuxièmement, l'ajout automatique d'un framework le marque comme «Obligatoire». Si votre application implique la possibilité de travailler "sous" les versions "iOS" inférieures à 12, cela entraînera également son plantage lors de la phase de démarrage "sous" les systèmes d'exploitation des versions inférieures. "AuthenticationServices" n'est disponible que pour les systèmes de la version 12. Ce problème est résolu en marquant le cadre comme
«facultatif» .
Prise en charge de la zone de texte
Pour prendre en charge la fonctionnalité avec des champs de texte, la variable
textContentType protocole
textContentType est
UITextInputTraits . La classe
UITextField , qui est très probablement utilisée pour entrer le login et le mot de passe dans l'application, implémente déjà les exigences du protocole dont nous avons besoin.
textContentType est un champ de type
UITextContentType contenant uniquement un ensemble de constantes. Ce dont nous avons besoin pour le moment, c'est
newPassword , utilisé pour entrer un nouveau mot de passe en cours d'invention (à ne pas confondre avec le seul
password utilisé pour entrer un mot de passe existant).
let passwordTextField = UITextField() if #available(iOS 12, *) { passwordTextField.textContentType = .newPassword }
La définition de la valeur de
textContentType encapsulée dans une vérification d'accessibilité
«API» , car, comme la fonctionnalité générale, cette constante n'est disponible qu'à partir de «iOS 12».
En plus du type de contenu, le champ de texte doit fournir une entrée de données sécurisée:
passwordTextField.isSecureTextEntry = true
Bien que l'application puisse fournir la fonctionnalité d'afficher et de masquer le mot de passe entré qui est populaire à notre époque, le mot de passe généré ne sera proposé que si le drapeau est
true à ce moment.
Un point intéressant est lié au type de contenu du champ de texte: si aucun autre champ n'est présent à l'écran, avec le
username type de contenu, le mot de passe généré automatiquement ne sera pas proposé. Cela est dû au fait que la fonctionnalité est basée non seulement sur le type spécifié de contenu de champ de texte, mais sur une
analyse heuristique du contenu de l'écran .
Il semble que la génération de mot de passe «casse» la logique des écrans qui nécessitent un nouveau mot de passe pour être vérifié deux fois. Au moins, je n'ai pas encore trouvé de moyen d'utiliser ces deux fonctionnalités ensemble. Et il semble que
je ne suis pas le seul .
Il convient de mentionner que si la connexion est sémantiquement une adresse e-mail (et, par conséquent, je veux vraiment avoir le type de clavier approprié), les
types de clavier et de contenu peuvent être combinés:
let userNameTextField = UITextField() userNameTextField.keyboardType = .emailAddress userNameTextField.textContentType = .username
Exigences de mot de passe
Souvent, les mots de passe des utilisateurs doivent suivre certaines règles (avoir une certaine longueur, inclure certains caractères, etc.). Ces règles peuvent être spécifiées pour que le système les prenne en compte lors de la génération des mots de passe. Cela se fait via la propriété
passwordRules du protocole
UITextInputTraits . Par exemple:
if #available(iOS 12, *) { passwordTextField.passwordRules = UITextInputPasswordRules(descriptor: "required: upper; required: lower; required: digit; minlength: 8;") }
La propriété est également disponible uniquement à partir de "iOS 12".
Le type de la propriété est
UITextInputPasswordRules . Initialisation - à l'aide d'une chaîne de descripteurs. Le descripteur a une syntaxe simple et se compose d'exigences de mot de passe simples, répertoriées avec un point-virgule. Chaque exigence est une paire clé-valeur, séparée par deux points. La clé est le type de règle (par exemple, "nécessairement inclut" -
required ), et la valeur est l'élément qui doit suivre cette règle (par exemple, chiffres -
digit ).
Dans l'exemple ci-dessus, le descripteur signifie:
required: upper - la présence d'au moins une majuscule est requise;required: lower - le même pour au moins une lettre minuscule;required: digit - le même pour au moins un chiffre en minuscule;minlength: 8 - la longueur minimale est de huit caractères.
Une liste détaillée des clés et valeurs possibles peut être trouvée dans un
bon article publié sur le site Web de NSHipster .
Et
Apple propose un
assistant de compilation de descripteurs plutôt pratique, qui fournit non seulement un moyen pratique de les construire, mais également une vérification des descripteurs compilés sous la forme d'un nombre illimité d'exemples générés. Vous pouvez y voir quelles règles sont appliquées par défaut.
Validation
Au cas où, il convient de préciser que le mécanisme de génération de mot de passe ne permet pas de valider les données saisies par l'utilisateur - vous devez vous en occuper vous-même. Ce qui, bien sûr, est assez logique, car l'utilisateur de l'application peut refuser le mot de passe généré automatiquement proposé ou même interdire la génération de mots de passe et l'auto-complétion des champs.
Constructeur d'interface
Ce qui est remarquable et dans l'esprit de notre temps, tous les paramètres de champ de texte répertoriés peuvent être définis dans le
"Interface Builder" , jusqu'à la "règle de mot de passe":
Vérification de fonctionnalité
La fonctionnalité n'est pas compliquée, mais elle a un certain nombre de nuances: lorsque vous la configurez, vous pouvez facilement oublier quelque chose. Dans ce cas, dans les assemblys "debug", lorsque le champ de texte correspondant est activé, la raison sera affichée dans la console pour laquelle la fonctionnalité ne fonctionne pas actuellement.
Par exemple:
[AutoFill] Cannot show Automatic Strong Passwords for app bundleID: <...> due to error: Cannot save passwords for this app. Make sure you have set up Associated Domains for your app and AutoFill Passwords is enabled in Settings
En outre, vous devez toujours garder à l'esprit que ce type de fonctionnalité fait partie des actions pour lesquelles l'autorisation de l'utilisateur est requise. Dans ce cas, deux sont requis:
1. Porte-clés iCloud;
2. Remplissage automatique.
Conclusion
Cela semble être tout ce à quoi il faut faire attention tout en fournissant un support pour les nouvelles fonctionnalités. Si quelqu'un en train de travailler sur cela a rencontré d'autres fonctionnalités intéressantes, je commenterai une fois et, si nécessaire, assurez-vous de compléter l'article.
La fonctionnalité est assez intéressante et, si elle est utilisée correctement, est tout à fait capable d'améliorer l'
expérience utilisateur de votre application!