Registro

[rafaelspa]

Como interessado eu quero me registrar para poder participar dos eventos.

Critérios de aceitação

• [x] O formulário deve ter os campos "nome completo", "e-mail", "CPF", "senha".
• [x] O campo nome deverá ter uma mensagem com referência ao fato de que esse nome constará no certificado.
• [x] O campo nome deverá conter nome e sobrenome e terá tamanho máximo de 256 caracteres e mínimo de 5.
• [x] Os campo CPF terá máscara XXX.XXX.XXX-XX.
• [x] O formulário deve ser condicionado ao aceite dos termos de uso com um link direcionando à eles. (Termo será escrito na próxima sprint)
• [x] O E-mail deve ter 350 caracteres no máximo, sendo no mínimo 64 para a parte "local" e 255 para a parte "domain" separadas pelo símbolo "@".
• [x] A validação do e-mail será case insensitive.
• [x] No e-mail não deve ser permitido caracteres perigosos, como backticks, aspas simples e duplas e null byte.
• [x] No e-mail deve ser permitido apenas letras, números, hífens e pontos na parte do "domain".
• [x] Todos os campos devem possuir a capacidade de copiar e colar.
• [x] Os campos devem seguir os respectivos tipos na construção da estrutura de marcação.
• [x] O CPF deve passar o critério aritmética de validação de CPFs.
• [x] O campo "senha" deve ter entre 8 e 64 caracteres e deve permitir caracteres unicode e espaço.
• [x] Os campo "senha" deve possuir no mínimo uma letra maiúscula, uma letra minúscula, um número e um caractere especial
• [x] Deve ser registrada a data do registro no banco.
• [x] Deve ser registrado um log de auditoria sobre o cadastro da conta
• [x] O campo "senha" deve ter uma opção de unmask.
• [x] Caso os campos sejam preenchidos incorretamente, deve-se exibir mensagens de erro ao lado do campo com a forma correta de se preencher.
• [x] Deve ter tooltips com a informação de onde a informação vai ser usada.
• [x] Avisar o registrante que o e-mail é imutável.
• [x] A página deve ter um link para a rota de login, com uma mensagem indicando a página de login.
• [x] A validação dos campos deve ter implementação no back-end.
• [x] Os campos devem ter validação por tipo.
• [x] Deve ser implementado query parameterization na comunicação com o banco.
• [x] A página deve ter um CAPTCHA.
• [x] O registrado terá o perfil PARTICIPANTE.
• [x] A senha será submetida à um algorítmo de hasheamento. (Ordem de preferência: Argon2, BCrypt, SCrypt)
• [x] Caso escolha Argon2, usar a versão Argon2id com configuração mínima de 15 MiB de memória, contagem de iteração 2 com um grau de paralelismo.
• [x] O registro de admins serão feitos diretamente no banco.
• [x] Deve-se verificar se existem registros duplicados por cpf e e-mail.
• [x] Se estiver duplicado avisar com uma mensagem avisando.
• [x] Um e-mail de confirmação com um link gerado de forma randômica será enviado para o e-mail informado com 15 minutos para expirar com uma mensagem avisando desse processo.
• [x] Os links de confirmação devem ter tokens de 32 caracteres, gerados usando uma fonte segura de randomicidade e de uso único.
• [x] Caso o e-mail seja expirado antes da confirmação, o registro será apagado do banco.
• [x] Após ter preenchido com sucesso o formulário, será exibida uma mensagem requisitando a confirmação do e-mail.
• [x] Após confimado o registro, o interessado será redirecionado para a página de login com uma mensagem de sucesso.

[rafaelspa]

O campo 'email' ficou sujeito às validações existentes nas próprias ferramentas. O campo senha, pelo próprio funcionamento do html, não pode ter a capacidade de copiar. O critério aritmético do CPF já existe pronto no backend. O front não tem esse critério. Foram acrescentadas mensagens indicando a correta formatação das informações exibidas antes de dar erro. Foi deixado de usar tooltips. Não há a necessidade de se avisar da imutabilidade do email Query parameterization não foi necessária devido aos recursos da ferramenta do backend. Foi adotado o algoritmo de hasheamento BCrypt. Foram gerados Tokens de Verificação de 15 minutos. Agora a confirmação do registro leva à página de reenvio de email.