| ... | ... | @@ -31,12 +31,34 @@ |
|
|
|
## 7.5 Arquitetura Não Funcional
|
|
|
|
|
|
|
|
***TODO***
|
|
|
|
<br><br>
|
|
|
|
|
|
|
|
## 7.6 Análise dos princípios SOLID
|
|
|
|
|
|
|
|
***TODO***
|
|
|
|
|
|
|
|
## 7.7 Segurança
|
|
|
|
#### Single Responsibility Principle:
|
|
|
|
O projeto possui três microsserviços separados em características macro: autenticação, pesquisas e respostas.
|
|
|
|
Cada microsserviço possui pacotes específicos para segurança, modelo de dados, comunicação com o banco de dados, modelo de saída, controladores e serviços.
|
|
|
|
Os controladores estão definidos conforme as rotas disponibilizadas, implementam um método para cada rota específica e delegam o processamento para os métodos de serviço.
|
|
|
|
|
|
|
|
***TODO***
|
|
|
|
#### Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle:
|
|
|
|
O projeto possui uma lógica concisa, direta e enxuta, logo suas classes não precisam de adptações, porém podem ser estendidas quando necessário.
|
|
|
|
Novas rotas e serviços podem ser facilmente criados com base nos já disponibilizados, sendo necessário apenas definição dos endpoints e da regra de negócio.
|
|
|
|
O projeto se vale de diversas abstrações, interfaces e anotações providas pelo framework Spring e outros terceiros, assim trata-se de uma implementação que segue boas práticas consolidadas no mercado, que possui fácil manutenção e extensão, e que pratica grande reúso.
|
|
|
|
<br><br>
|
|
|
|
|
|
|
|
## 7.7 Segurança
|
|
|
|
A segurança do projeto foi implementada utilizando a dependência <a href="https://spring.io/projects/spring-security">Spring Security</a> e a autenticação utilizando <a href="https://jwt.io/>jsonwebtoken </a>. Funcionalmente a segurança é implementada da seguinte forma:
|
|
|
|
- A rota de cadastro da api de autenticação permite registrar usuários com no mínimo cinco informações nome completo, usuário, e-mail, senha e papel (name, username, email, password e role).
|
|
|
|
- Os possíveis papéis (roles) de usuários no sistema são
|
|
|
|
* ROLE_ADMIN - administrador, só pode ser cadastrado localmente no servidor da aplicação
|
|
|
|
* ROLE_RESEARCHER - pesquisador, cadastro via tela de cadastro em qualquer browser web
|
|
|
|
* ROLE_RESPONDENT - respondente, cadastro via tela de cadastro em qualquer browser web
|
|
|
|
- A rota de login da api de autenticação permite que um usuário faça login no sistema utilizando usuário ou e-mail e senha. Ao validar as credenciais do usário a api retornar um token jwt que é salva pelo cliente front-end para acessar rotas protegidas do sistema.
|
|
|
|
- Os clientes devem mandar o token jwt no header de cada requisição que acessar rotas protegidas.
|
|
|
|
- O Spring Security será o responsável por restringir o acesso às rotas conforme abaixo:
|
|
|
|
* rotas de cadastro, login e, se necessário, recursos estáticos como imagens e scripts são acessíveis a todos que acessarem a página web do sistema, mesmo que não estejam autenticados.
|
|
|
|
* rotas de consulta a pesquisas cadastradas necessitam apenas que o usuário esteja logado.
|
|
|
|
* rotas para criar e editar pesquisas necessitam que o usuário esteja logado como administrador ou pesquisador, sendo que é possível editar apenas pesquisas cadastradas pelo próprio usuário logado.
|
|
|
|
* rotas para iniciar e finalizar uma resposta podem ser acessadas apenas por usuário respondentes.
|
|
|
|
* rotas que deletam fisicamente registros de usuários, pesquisas e respostas são acessadas apenas por usuários administradores.
|
|
|
|
<br><br> |
