Se seu aplicativo possui uma função de registro que inclui a capacidade ou a necessidade de inserir um novo nome de usuário e senha, provavelmente você estará interessado na inovação do
iOS 12 , que eu gostaria de descrever. Este é um serviço que inventa novas senhas para o usuário, as substitui automaticamente nos campos necessários e as armazena com segurança no
Keychain .
As senhas geradas automaticamente pelas senhas do sistema são as mais resistentes à seleção (sendo seqüências de caracteres geradas aleatoriamente - ajustadas para restrições personalizadas, mas mais sobre isso posteriormente), dispensam os usuários do aplicativo da necessidade de criar uma sequência própria e são configurados de forma flexível para as necessidades de um aplicativo específico. O suporte para novas funcionalidades é facilmente fornecido, no entanto, não sem recursos. Mas as primeiras coisas primeiro.
Direitos e Obrigações
Primeiro de tudo, o aplicativo deve declarar seu desejo de usar essa funcionalidade. Na lista
Recursos do
Destino correspondente
, você deve primeiro ter um domínio na lista
Domínios Associados . Curiosamente, o aplicativo deve ter um "Domínio Associado" para poder usar as senhas geradas e armazená-las no "Porta-chaves" do usuário (essas duas funções são interconectadas e a geração não pode ser usada separadamente do armazenamento).
Se o aplicativo já suportar o
uso de contas compartilhadas com o seu site (as chamadas "Credenciais Compartilhadas") , então esta etapa já está atrasada. Ele também pode estar atrasado e se o aplicativo suportar
Universal Links ou outro mecanismo para processar
"URLs" externos.
De qualquer forma, depois de adicionar essa compatibilidade, o aplicativo terá um novo
"Direito" .
Além dessa compatibilidade mais geral, o aplicativo também deve ter “Capatibilidade”
“Fornecedor de credenciais de preenchimento automático” - isso permite que o aplicativo, se houver permissão do usuário, use os logins e senhas oferecidos pelo sistema. A adição dessa compatibilidade fará com que a permissão de
Titularidade do provedor de credenciais de preenchimento automático seja exibida .
A propósito, a adição deste e de outros recursos está disponível apenas para membros do Apple Developer Program .
O perfil de provisionamento usado pelo aplicativo também deve incluir os dois recursos a seguir.
Dependências usadas
Adicionar compatibilidade apropriada resultará na aparência da
estrutura AuthenticationServices na lista de Frameworks e Bibliotecas Vinculadas do destino correspondente. Este ponto tem alguns recursos que vale a pena mencionar.
Primeiro, a adição automática de uma estrutura relacionada pode não "funcionar" na primeira vez: quando inicio o aplicativo em um dispositivo real a partir da minha cópia do
"Xcode" versão 10.1, o aplicativo imediatamente "travou" devido à falta de "AuthenticationServices". Remover manualmente a estrutura e adicioná-la novamente à lista de componentes relacionados resolveu o problema.
Em segundo lugar, a adição automática de uma estrutura a marca como "Necessária". Se o seu aplicativo implicar a possibilidade de trabalhar "nas versões" "" iOS "abaixo de 12, isso também causará uma falha na fase de inicialização" nos "sistemas operacionais" de versões inferiores. "AuthenticationServices" estão disponíveis apenas para sistemas da versão 12. Esse problema é resolvido marcando a estrutura como
"Opcional" .
Suporte para caixa de texto
Para dar suporte à funcionalidade com campos de texto, a variável
textContentType protocolo
textContentType é
UITextInputTraits . A classe
UITextField , que provavelmente é usada para inserir o login e a senha no aplicativo, já implementa os requisitos do protocolo que precisamos.
textContentType é um campo do tipo
UITextContentType contém apenas um conjunto de constantes. O que precisamos no momento é
newPassword , usado para inserir uma nova senha que está sendo inventada no momento (não confunda apenas com a
password usada para inserir uma senha existente).
let passwordTextField = UITextField() if #available(iOS 12, *) { passwordTextField.textContentType = .newPassword }
A configuração do valor de
textContentType em uma verificação de acessibilidade da
"API" , porque, como a funcionalidade geral, essa constante está disponível apenas a partir do "iOS 12".
Além do tipo de conteúdo, o campo de texto deve fornecer entrada de dados segura:
passwordTextField.isSecureTextEntry = true
Embora o aplicativo possa fornecer a funcionalidade de exibir e ocultar a senha inserida que é popular em nossos dias, a senha gerada será oferecida apenas se, neste momento, o sinalizador for
true .
Um ponto interessante está conectado ao tipo de conteúdo do campo de texto: se nenhum outro campo estiver presente na tela, com o
username tipo de conteúdo, a senha gerada automaticamente não será oferecida. Isso se deve ao fato de a funcionalidade ser baseada não apenas no tipo especificado de conteúdo do campo de texto, mas em uma
análise heurística do conteúdo da tela .
Parece que a geração de senha "quebra" a lógica das telas que exigem que uma nova senha seja inserida duas vezes para verificar. Pelo menos ainda não encontrei uma maneira de usar essas duas funcionalidades juntas. E parece que
eu não sou o único .
Vale ressaltar que, se o login for semanticamente um endereço de e-mail (e, portanto, eu realmente quero ter o tipo de teclado apropriado), os
tipos de teclado e conteúdo podem ser combinados:
let userNameTextField = UITextField() userNameTextField.keyboardType = .emailAddress userNameTextField.textContentType = .username
Requisitos de senha
Freqüentemente, as senhas dos usuários devem seguir certas regras (ter um certo comprimento, incluir certos caracteres etc.). Essas regras podem ser especificadas para que o sistema as leve em consideração ao gerar senhas. Isso é feito através da propriedade
passwordRules do protocolo
UITextInputTraits . Por exemplo:
if #available(iOS 12, *) { passwordTextField.passwordRules = UITextInputPasswordRules(descriptor: "required: upper; required: lower; required: digit; minlength: 8;") }
A propriedade também está disponível apenas a partir do "iOS 12".
O tipo da propriedade é
UITextInputPasswordRules . Inicialização - usando uma cadeia de caracteres do descritor. O identificador possui uma sintaxe simples e consiste em requisitos simples de senha, listados com ponto e vírgula. Cada requisito é um par de valor-chave, separado por dois pontos. A chave é o tipo de regra (por exemplo, "inclui necessariamente" -
required ) e o valor é o elemento que deve seguir essa regra (por exemplo, dígitos -
digit ).
No exemplo acima, o descritor significa:
required: upper - é necessária a presença de pelo menos uma letra maiúscula;required: lower - o mesmo para pelo menos uma letra minúscula;required: digit - o mesmo para pelo menos um dígito em minúsculas;minlength: 8 - o comprimento mínimo é de oito caracteres.
Uma lista detalhada de possíveis chaves e valores pode ser encontrada em um
bom artigo publicado no site do NSHipster .
E a
Apple oferece um
assistente de compilação de descritores bastante conveniente, que fornece não apenas uma maneira conveniente de construí-los, mas também uma verificação dos descritores compilados na forma de um número ilimitado de exemplos gerados. Lá você pode ver quais regras são aplicadas por padrão.
Validação
Por precaução, deve ser esclarecido que o mecanismo de geração de senha não fornece validação dos dados inseridos pelo usuário - você mesmo deve cuidar disso. O que, é claro, é bastante lógico, porque o usuário do aplicativo pode recusar a senha gerada automaticamente proposta ou até mesmo proibir a geração de senhas e o preenchimento automático de campos.
Construtor de interface
O que é digno de nota no espírito de nosso tempo, todas as configurações de campos de texto listadas podem ser definidas no
"Interface Builder" , até a "Regra de senha":
Verificação de funcionalidade
A funcionalidade não é complicada, mas possui várias nuances: quando você a configura, pode facilmente esquecer algo. Nesse caso, nas montagens "debug", quando o campo de texto correspondente é ativado, o motivo será exibido no console para o qual a funcionalidade não está funcionando no momento.
Por exemplo:
[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
Além disso, lembre-se sempre de que esse tipo de funcionalidade está entre as ações para as quais é necessária a permissão do usuário. Nesse caso, são necessários dois:
1. Chaveiro do iCloud;
2. Preenchimento automático.
Conclusão
Parece ser tudo o que deve ser prestado atenção ao fornecer suporte para novas funcionalidades. Se alguém no processo de trabalhar nisso tiver encontrado outros recursos interessantes, comentarei uma vez e, se necessário, certifique-se de complementar o artigo.
O recurso é bastante interessante e, se usado corretamente, é capaz de melhorar a
experiência do usuário do seu aplicativo!