Closed rafas closed 1 year ago
@murilohns Valeu A falha pode ter a ver com o nock estar ouvindo outro endereço.. Não tinha atentado pra esse detalhe.. Teria que cancelar essa PR e enviar uma nova com as specs atualizadas, ou pode alterar os testes em outra PR?
@rafas pode fazer nesse mesmo PR :)
Mestre @rafas primeiramente muito obrigado por informar o que tava rolando com o serviço antigo e ter a preocupação de inclusive atualizar aqui no projeto a referência ❤️ A gnt tem passado por alguns "ataques" tbm no BrasilAPI especialmente nas rotas de CEP que tem sido bem difícil conter sem extrapolar os limites da Vercel e da Cloudflare mas ainda estamos conseguindo conter e manter como uma API pública e de uso anônimo 🙏
Dúvida vi que ta tomando cap aqui, isso é esperado mesmo? 👀
Salve @lucianopf Esse bloqueio não era esperado. Escolhemos um provedor s3 compatível que em tese não onera tráfego vinculado ao CDN, e mesmo que todos os CEPs da base fossem baixados 10 vezes no mesmo dia contabilizando o tráfego, ainda assim não atingiria o limite estabelecido. Mas parece que fomos testados e algo deu errado.
Estamos tentando achar uma solução que nos permita manter isso funcionando, mas visto como os ataques antigos foram feitos na API antiga, com dumps sincronizados vindos de vários IPs simultâneos de faixas parecidas, parece ser algo proposital e difícil de ter respaldo comum de um cache de CDN.
Pelo que notei a api nova está funcionando, não sei se está intermitente. O que acham de fazermos um release de preview e monitorarmos? Eu me candidataria para este piloto, inclusive pq tenho uma quantidade bem grande de erros por rate-limit na widenet ( https://github.com/BrasilAPI/cep-promise/issues/244 ).
@rafas se quiser podemos te ajudar com a correção dos testes também
@rafas você tem algum update sobre isso?
Pelo que notei a api nova está funcionando, não sei se está intermitente. O que acham de fazermos um release de preview e monitorarmos? Eu me candidataria para este piloto, inclusive pq tenho uma quantidade bem grande de erros por rate-limit na widenet ( #244 ).
@rafas se quiser podemos te ajudar com a correção dos testes também
@ericksprengel a gnt pode organizar isso sim hein! Lançar uma nova release com esse update e sem a widenet como provedor padrão e quem quiser adicionar pra usar como validação igual vc falou
@ericksprengel a gnt pode organizar isso sim hein! Lançar uma nova release com esse update e sem a widenet como provedor padrão e quem quiser adicionar pra usar como validação igual vc falou
A alteração do widenet de provedor padrão pra opcional fazemos em um novo PR?
O @GustavoDinizMonteiro abriu um PR pro fork do @rafas arrumando os testes. Não sei qual o fluxo vocês preferem seguir. O que acham @lucianopf @rafas ?
@murilohns e @lucianopf eu concertei os testes no meu fork, teria alguma outra alternativa para seguirmos com esse PR ? Seria melhor eu abrir um PR a partir do meu fork para que possamos dar seguimento nessa correção ?
sim @GustavoDinizMonteiro, abrir um PR do teu Fork é a solução mais rápida
@murilohns fiz esse novo PR https://github.com/BrasilAPI/cep-promise/pull/256 Estamos fazendo testes com o uso da nova api da widenet, poderia revisar
fechado pelo #256
Minha primeira contribuição aqui, não sei se tem algum padrão, mas segue a proposta de mudança
Estamos fechando o acesso público ao ws.apicep.com e pra não deixar a comunidade sem acesso, criamos uma alternativa que oferece exatamente os mesmos dados, mas baseado em um CDN de arquivos estáticos em um S3, atualizados de forma assíncrona.
Nossa proposta pro webservice antigo era buscar os dados do CEP em tempo real caso ele esteja desatualizado ou não exista em nossa base, porém devido ao volume gigantesco de pesquisas de CEPs inválidos (tentativas de dump forçado, scraping, etc) nossa fila de atualizações ficava quase sempre prejudicada, mesmo com restrições de flood e etc.
O acesso público novo não tem limite de consulta e não tem restrição cors. Exemplo do novo endereço: https://cdn.apicep.com/file/apicep/64009-140.json
Fico à disposição