Mudança de comportamento no PR #151

[crazynds]

Hoje acabei de receber um erro que todos os meus validadores de CPF e CNPJ estão falhando. Indo investigar percebi que a biblioteca simplesmente dropou suporte para validação de CPF e CNPJ se não estiver formatado com pontos conforme o format abaixo:

validator-docs/src/validator-docs/Formats/Cpf.php

Lines 7 to 13 in 7d0040c

	class Cpf implements ValidatorFormats
	{
	public static function validateFormat(string $value): bool
	{
	return preg_match('/^\d{3}\.\d{3}\.\d{3}-\d{2}$/', $value) > 0;
	}
	}

CPF que não funcionam que funcionavam em versões anteriores:

• 70851081002
• 053770350-03

Já uso a biblioteca a muitos anos, mas vou ter que dropar o uso da biblioteca por essa mudança de comportamento...

[geekcom]

Oi @crazynds, na real essa atualização melhora a segurança da lib, pois agora temos certeza que um CPF é de fato válido, antes da versão 3.11.0 um CPF com letras no final por exemplo, era considerado válido. O contra ponto é que agora será necessário como você citou, passar o CPF no formato válido 000.000.000-00, incluindo todos os caracteres. No futuro vamos melhorar isso também para CNPJ e revisar as outras validações.

[crazynds]

Eae @geekcom,
Concordo com você na parte de melhorias em relação ao sistema de validar caracteres alfanumericos que antes pegaria incorretamente.

Porém acredito em 2 pontos fortes para que essa atualização não tivesse vindo da forma que veio:

• ate o momento, a biblioteca suportava cpfs apenas numeros, que é o caso que eu e diversos devs usam. Mesmo com formatação no frontend, o endpoins é exposto via api, para qualquer conexão ser feita, enviando com ou sem pontos. Essa alteração muda totalmente esse comportamento.
• se essa alteração é uma decisão da biblioteca de ser tomada, deveria ter vindo como update major, visto que quebra uma funcionalidade totalmente válida anterior (aceitar cpfs apenas numeros).

E um ponto que discordo é que no desenvolvimento na questão de santizacão antes do request. Sempre trabalhei com a ideia de que o usuario pode enviar um email com letras maiusculas, cpf sem ponto entre outras, e atribuir essa formatação como função do frontend é dar um tiro no pé, pois temos aplicações desktop, app, pagina web, chamadas de api, integrações e diversas outras fontes, então como estratégia a formatação final sempre deveria ser feita no backend pre saving (usando Events, observers, casts, entre outros...)

Outro ponto de sanitizar em algum dos metodos que falei é mais seguro, é em caso de algum outro dev trabalhar em um método que também altera algum campo que deveria ser sanitizado e ele não faz esse tratamento. Ao sanitizar direto na model, garantimos que qualquer alteração passa pelo sanitizador.

[geekcom]

Seu ponto faz sentido, eu vou fazer um revert na task por enquanto, depois voltamos a discutir isso, espero que alguém mande esse PR, pois no momento eu tô sem tempo pra trabalhar nisso.

[geekcom]

Obrigado pela observação @crazynds foi de grande ajuda, atualizei a versão para 3.11.1

[geekcom]

Eu havia fechado a issue, mas vou deixar pra vc mesmo fechar

#154

[crazynds]

Obrigado, acredito que podemos estudar alguma possibilidade de colocar a formatação de pontos e traços como opcional (seria uma alteração facil no regez), ou colocar um meio de selecionar se queremos uma validação estrita ou apenas os números (ainda validando se não tem alfanumericos invalidos)

Posso fazer um PR se necessário mas acho melhor discutir a ideia primeiro.

[ajconradie]

why don't you guys create PROPER test cases and code accordingly ? - you guys really seem unprofessional and not good dev's - sorry to say ....