search

OpenDevUFCG / laguinho-api

Onde todos os dados, pessoas e radiação da UFCG se encontram.
MIT License
28 stars 18 forks source link

Como disponibilizar o laguinho pra todo mundo? #21

Closed JoseRenan closed 5 years ago

JoseRenan commented 5 years ago

Pessoas, o laguinho já tá em pé e etc, mas a gente precisa restringir o acesso a ele, pra gente evitar flood malicioso e saber quem tá acessando, uma forma que pensei de fazer isso foi ter um sistema de dev account pra vc gerar seu token, mais ou menos como é feito nas APIs do github, spotify, twitter, facebook e etc, o que acham? e como vcs acham que a gente podia botar isso pra funcionar?

JoseRenan commented 5 years ago

/cc @paulojbleitao @juliobguedes @thayannevls @JuanBarros2

JuanBarros2 commented 5 years ago

Acho bom isso mas sei que existem ferramentas pra restringir isso sem precisar token. Acho que é o NGinx que faz isso se não me engano

JuanBarros2 commented 5 years ago

A gente usa algumas no projeto do analytics, acho que posso perguntar mais detalhes para o pessoal que entende

danielmitre commented 5 years ago

Reforçando a sugestão do nginx: https://serverfault.com/questions/845554/handling-http-flood-via-webserver-configuration-django-app

JoseRenan commented 5 years ago

O que eu não gosto sobre NGINX (dadas nossas condições de infraestrutura kkkk) é precisar ter uma VM rodando com ele na frente do app, e com um token a gente poderia simplesmente matar o token em caso de uso malicioso do laguinho apesar de só conseguir pensar em flood no momento 🤔

danielmitre commented 5 years ago

No caso do token, todo mundo que fosse fornecer um projeto que usasse algum dado via laguinho precisaria fazer um tratamento/cache server-side e fornecer ele mesmo a API usando o próprio token tendo cuidados para não floodar. Deve funcionar, mas também não parece muito amigável.

Uma opção é criar um pequeno hand-shake de autenticação que requer resolver um hash que gastará alguns segundos pra ser calculado. Nesse caso o flood mirando uma API seria tecnicamente inviável, mas ainda poderia haver um DoS criando conexões e não resolvendo os hashs.

Uma terceira opção que não deve afetar a infraestrutura do servidor é de fato fazer algum gerenciamento de IP e/ou controle de recursos no node, não deve ser difícil de implementar algo bom o bastante através de um middleware, mas já existem vários pacotes no node para isso.

JuanBarros2 commented 5 years ago

Conversei com um colega de trabalho que tem experiencias em projetos open source e web e ele falou pra avaliar previamente se é mesmo necessário. Ele falou que foram poucas as vezes que isso realmente aconteceu nos sistemas que ele participou, mas recomendou o uso do NGinx.

JuanBarros2 commented 5 years ago

Ele falou também que criar token pode ser uma barreira a mais pra quem quer utilizar a endpoint e que só usaria se achasse que era realmente necessário via demanda dos usuários.

thayannevls commented 5 years ago

Fico pensando se vale essa discussão tão cedo sem sabermos ainda do que realmente precisamos e tendo tão poucas endpoints e pessoas usando.

JuanBarros2 commented 5 years ago

O ultimo ponto que ele falou foi sobre dar mais importância ao tempo de resposta via BD. Ele falou que isso costuma ser um gargalo mais recorrente e que deveríamos considerar antes de se preocupar com esses ataques em massa.

JuanBarros2 commented 5 years ago

Concordo com @thayannevls. Acho que talvez no máximo caiba adicionar um NGinx, pois ele já trata de algumas questões triviais de segurança que a gente não teria tempo de implementar. Fora isso, acho que seria perder tempo em outras questões mais importantes mesmo.

thayannevls commented 5 years ago

Resolvido aqui #31

https://github.com/OpenDevUFCG/laguinho-api/issues/31#issuecomment-517514522