search

discentes-imd / IntegraTI-API

API RESTful para o projeto IntegraTI
https://api-integrati.herokuapp.com/
GNU General Public License v3.0
6 stars 0 forks source link

Caso de uso 01 - Realizar login #3

Closed rodrigondec closed 4 years ago

rodrigondec commented 7 years ago

Implementar sistema de login de acordo com a documentação

felihenrique commented 7 years ago

Sessões creio que devem ficar no servidor, por questões de segurança.

rodrigondec commented 7 years ago

Não sei como seria gerenciada uma sessão por uma aplicação restful, pois a chave da sessão fica in cache no navegador ou como coockie. Mas enfim, veremos então como fazer isso no flask

Mazuh commented 7 years ago

Uma API RESTful é, por definição, stateless. É ~anti pattern~ delicado manter uma autenticação de usuário no servidor que implementa a abstração REST.

Deste artigo da Wikipédia:

Na prática, muitas aplicações baseadas em HTTP utilizam cookies e outros mecanismos para manter o estado da sessão (algumas destas práticas, como a reescrita de URLs, não são permitidas pela regra do REST).

Há uma discussão interessante (de caras que usam JS no front e o Flask-Restful no server) aqui no próprio repositório do pacote Flask-Restful: https://github.com/flask-restful/flask-restful/issues/492

Seria interessante buscar nos códigos deles se eles fizeram alguma implementação do tipo.

DavidCardoso commented 7 years ago

Podemos utilizar um tabela no MySQL ou um NoSQL para armazenar e gerenciar as sessões. Dessa forma, mantemos stateless. Outro ponto que tem q ser resolvido é sobre onde armazenar os arquivos/anexos. Se eles ficarem direto no servidor web, a aplicação como um todo não será stateless. Se o objetivo for deixar 100% stateless, é importante tbm pensar nisso. Por exemplo, AWS Upload para S3

Mazuh commented 7 years ago

@davidcardoso-ti, acho que era mais simples delegar esse gerenciamento pro node ao invés do mysql, não? Realmente não sei qual a melhor solução nesse caso.

E outra issue pra tratar de upload (porque... é outra issue).

DavidCardoso commented 7 years ago

@Mazuh, voei no "node"? rs Esse tipo de controle (sessão + stateless) tem q ser em algum banco (relacional ou NoSQL). Pois, sempre teremos um servidor de banco que será acessado pelas instâncias do WS. Mas, para o website e para o WS, podemos usar infraestrutura em nuvem (gerenciado, elástico, etc) que demanda uma aplicação 100% stateless para poder usar adequadamente os recursos de nuvem sem "quebrar" a aplicação. Por exemplo, como nosso frontend terá apenas arquivos estáticos (JS, HTML, CSS, Imagens, etc), podemos servir o website totalmente pelo AWS S3 sem necessariamente ter um servidor web (ISS, Apache, etc). O WS poderia ficar sob um Load Balancer (com várias instâncias) + um Auto Scaling. E, por último, teríamos um servidor de banco de dados relacional (MySQL). image

DavidCardoso commented 7 years ago

Podemos conversar mais sobre isso na próxima reunião.

rodrigondec commented 7 years ago

Voltando para uma outra discussão, a criação da conta no sistema será feita no primeiro login utilizando a API do Sigaa.

Porém, teremos um login e senha para o usuário em nosso sistema então?

Ou o login só será feito através da API do Sigaa (e nosso sistema não saberá da senha do usuário nem terá esse registro) como @felihenrique mencionou no whats?

DavidCardoso commented 7 years ago

Uma ideia: O usuário ser independente de API's externas (SIGAA, Facebook, Google, etc). Porém, para determinadas áreas e recursos do IntegraTI, o usuário necessitaria de um nível a mais de autenticação. Por exemplo, para interagir com disciplinas/turmas ele precisaria se autenticar tbm com o SIGAA.

Dessa forma, deixaríamos já previsto qualquer tipo de usuário e iríamos habilitando esses outros níveis de autenticação a medida que novos recursos fossem sendo liberados e precisassem de tais autenticações em API's externas.

Esse é o modelo que as ferramentas usam atualmente para se integrarem (Slack+Github, por exemplo).

Mazuh commented 7 years ago

@davidcardoso-ti, mas esse modelo funciona bem porque as ferramentas já tem funções principais bem independentes daquelas com que se integram (o Slack só "precisa" se integrar ao GitHub por conveniência, mas todas as funções principais dele independem). O nosso sistema é composto majoritariamente de coisas que dependem da autenticação do Sigaa (no sentido de que ela pode afirmar que o indivíduo tem vínculo ativo com a UFRN e pode realizar analogica/concretamente todas funções que provemos digitalmente). Mesmo assim eu gostei da ideia de termos um login independente, mas bem ligado à autenticação do Sigaa. Precisamos desenvolver melhor a ideia.

(sobre o node, perdão, me referi ao front mesmo que creio estar em angular... com os frameworks deles deve ser bem easy manter sessões sem aumentar a demanda de atividades no servidor API, não?)

rodrigondec commented 7 years ago

Porém esse primeiro módulo de eventos seria aberto tbm pra pessoas que não são estudantes, não? Por isso acho válido a ideia.

Mazuh commented 7 years ago

@rodrigondec, a leitura de dados seria aberta pra todos. Mas não creio que seja interessante abrir pra o cadastro de eventos por qualquer um. Acho que fugiria do que o projeto propõe.

De qualquer forma, não acho que é uma decisão que caiba a nós programadores. É preciso averiguar os requisitos com os representantes do curso e levar essa discussão a eles.

felihenrique commented 7 years ago

Acho que a solução do @davidcardoso-ti é a melhor, pra questão de ser stateless. Geralmente o sistema armazena um token, que ele gera quando o usuario se autentica, que tem um tempo de validade.