You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hoje o sistema possui apenas Validações de Negócio (também conhecidas como Validação de Domínio, Validação Semântica ou mais popularmente como Regras de Negócio). Estas validações são encontradas de forma mais profunda no nosso sistema como, por exemplo, não deixar que dois usuários tenham o mesmo email, que não seja possível localizar uma session caso o expires_at já tenha ultrapassado X segundos ou que uma ação no sistema possa ou não possa ser realizada conforme um user tenha ou não uma determinada feature.
Diferente disso são as Validações Sintáticas, que são validações mais superficiais, onde o único objetivo é validar o formato do dado em si como, por exemplo, se o campo password possui no mínimo X e no máximo Y caracteres, se o campo email de fato possui uma string contendo um dado num formato de email válido, se o valor informado está dentro de uma lista de valores esperados, ou até se um campo é obrigatório ou opcional.
Apesar das Validações Sintáticas serem mais superficiais, elas são extremamente importantes, pois são colocadas na borda da API (antes até de processar qualquer coisa dentro do controller) para barrar a entrada de “lixo” para dentro do sistema, o que irá inibir inúmeros vetores de ataque.
Então a partir daqui uma regra muito importante precisa ser estabelecida: nenhuma informação que entrar dentro do sistema pode ser utilizada antes de ser validada, simplesmente nenhuma.
Execução
Criar um novo model chamado validator que deve expor uma interface pública simples para definir quais campos devem ser validados. Caso a validação esbarre em algum campo inválido, devolver qual o nome do campo para isto ser usado no frontend.
Contexto
Hoje o sistema possui apenas
Validações de Negócio(também conhecidas comoValidação de Domínio,Validação Semânticaou mais popularmente comoRegras de Negócio). Estas validações são encontradas de forma mais profunda no nosso sistema como, por exemplo, não deixar que dois usuários tenham o mesmo email, que não seja possível localizar umasessioncaso oexpires_atjá tenha ultrapassadoXsegundos ou que uma ação no sistema possa ou não possa ser realizada conforme umusertenha ou não uma determinadafeature.Diferente disso são as
Validações Sintáticas, que são validações mais superficiais, onde o único objetivo é validar o formato do dado em si como, por exemplo, se o campopasswordpossui no mínimoXe no máximoYcaracteres, se o campoemailde fato possui uma string contendo um dado num formato de email válido, se o valor informado está dentro de uma lista de valores esperados, ou até se um campo é obrigatório ou opcional.Apesar das
Validações Sintáticasserem mais superficiais, elas são extremamente importantes, pois são colocadas na borda da API (antes até de processar qualquer coisa dentro do controller) para barrar a entrada de “lixo” para dentro do sistema, o que irá inibir inúmeros vetores de ataque.Então a partir daqui uma regra muito importante precisa ser estabelecida: nenhuma informação que entrar dentro do sistema pode ser utilizada antes de ser validada, simplesmente nenhuma.
Execução
validatorque deve expor uma interface pública simples para definir quais campos devem ser validados. Caso a validação esbarre em algum campo inválido, devolver qual o nome do campo para isto ser usado no frontend.PATCH/api/v1/activations/[token_id]token_idPOST/api/v1/sessionsemailepasswordPOST/api/v1/usersusername,emailepasswordsession_idImportant
Neste primeiro momento fazer apenas a validação de entrada de dados, sem precisar fazer a validação de saída de dados.