Customização dos campos de Auth, passando os campos e os respectivos tipos de dado + Documentação no README

[adilsonjuniordev]

Olá @rodrigorahman e @brasizza, espero que vocês estejam bem!

Proposta

Conversei com o Rodrigo sobre a minha ideia, e ele aprovou a proposta, então decidi fazer este PR e venho solicitar que façam uma análise por favor, e qualquer dica que tiverem, ou ajuste necessário, estou disposto a complementar.

A ideia principal dessa implementação, é que o usuário do Json Rest Server tenha a possibilidade de personalizar o método de autenticação e os campos recebidos na request. Atualmente o padrão é "email" e "password", ambos como String.

Me surgiu uma necessidade de fazer um mock de uma API que utiliza CPF, telefone e data de nascimento para fazer a autenticação, com isso surgiu a ideia dessa implementação.

---

Implementação

No arquivo de configurações config.yaml, criei um novo parâmetro authFields, no qual devem ser passados os campos que serão validados na request de login. Esses campos devem ser passados juntamento com o seu nome + tipo de dado, que podem ser (string, int ou double)

Segue abaixo um exemplo:

auth:
  jwtSecret: cwsMXDtuP447WZQ63nM4dWZ3RppyMl
  jwtExpire: 604800

  authFields:
    - documento:
        type: string
    - celular:
        type: int

  urlSkip:
    - /users:
        method: post

Como o authFields é opcional, caso o parâmetro não seja definido no config.yaml, o JRS manterá a autenticação padrão, que utiliza "email" e "password", ambos como string.

Considerações Finais

Conforme falei com o Rodrigo, eu não tive possibilidade de implementar os testes, então isso está pendente. Percebi que não existe testes para quando o Auth está habilitado, então antes de fazer os testes para o authFields, eu teria que implementar os testes de Auth, e estou sem tempo para fazer isso no momento.

Caso consigam me ajudar com os testes, fico agradecido.

Obrigado pela atenção,
Abraço!

[brasizza]

@adilsonjuniordev , achei uns bugzinhos, estou corrigindo e mando pra vc em comentario

[brasizza]

Aqui faltou uma associação do user
user = users.firstWhere()
quando nao tem o auth config sempre retorna empty porque vc ta associando la em cima o user

[adilsonjuniordev]

Aqui realmente foi um erro, eu estava mexendo e acabei esquecendo de voltar a atribuição. Bem observado! Vou corrigir.

[brasizza]

vc ta fazendo 2 verificações que nao precisa OU ele é vazio ou nao é vc pode alterar isso pra um if/else

exemplo

if (authConfig?.authFields.isEmpty ?? true) {
        user = users.firstWhere(
          (user) {
            return (user['email'] == bodyData['email'] && user['password'] == bodyData['password']);
          },
          orElse: () => {},
        );
      } else {
        int numberOfFields = authConfig!.authFields.length;
        
          //aqui continua seu codigo
        }

[adilsonjuniordev]

Ok, vou ajustar isso também

[adilsonjuniordev]

@brasizza , subi as correções, verifica se está ok por favor

[brasizza]

Eu tava com o meu config autenticando por cnpj, ai eu tirei sem querer no json de auth e ele comecou a pipocar erro com exception nao tratada pois quando chegava no
bodyData[field.name]. esse fieldname nao existia na lista e estourava um monte de erro,

então fiz uma correção para quando ele estiver percorrendo os fields ele olha pra ver se esse field tem no bodyData, e se nao tiver já retorna um 500 informando que tem alguma coisa errada na autenticação com os campos

    for (var field in authConfig.authFields) {
              if (!(bodyData as Map).containsKey(field.name)) {
                return Response(
                  500,
                  body: jsonEncode({'error': 'field ${field.name} not found in validation. Please check if you put this validation in config.yaml  then remove it or send the correct fields to authenticate'}),
                  headers: jsonHelper.jsonReturn,
                );
              }
            }

Veja se isso faz sentido pra vc!

[adilsonjuniordev]

Ótimo!!

[brasizza]

@rodrigorahman , com as alterações e correções propostas, o PR ta LEGIT.

1. Os impactos são nulos quando não existe a configuração no yaml
2. Quando existe, fizemos a verificação que se esse campo escolhido existe na requisição POST, retornando um 500 tratado caso não exista.
3. Corretamente verificado e testado quando o campo existe, e o dado existe.