Contexto
Uma plataforma como o TabNews pode se beneficiar de ter um Sistema de Autorização granular e isso significa que, ao invés de usuários terem credenciais como Administrador ou Editor que agrupam várias sub-credenciais, seria interessante o sistema ter a possibilidade de atribuir permissões específicas e fragmentadas, diretamente associadas a cada usuário.
Com isto, um usuário novo no site pode ter a permissão e credencial para criar respostas na plataforma, porém não ter a permissão para criar publicações principais (as que aparecem na Home) e só irá ganhar esta permissão após alcançar um determinado nível de engajamento. Ou no caso de um moderador ganhar o poder de editar a publicação de outros usuários, mas não ganhar a permissão de ver o email dos usuários e nem conseguir rodar as migrations do sistema.
Seja qual for o caso, um sistema mais granular se torna mais flexível e capaz de se adaptar a diferentes cenários e necessidades de segurança, permitindo uma administração mais precisa dos direitos de cada usuário.
Execução
Como descrito na seção Contexto, o sistema não deveria ser "Role-based Access Control" e deveria ser mais algo como "Resource-based Access Control".
Tudo isto deveria ser controlado pelas features que um usuário possui e para na prática ter esse controle nós devemos:
- Usar middlewares do
next-connect para sempre injetar um usuário na requisição, seja este um usuário autenticado e com um conjunto de permissões, seja um usuário anônimo em com outro conjunto de permissões.
- Após isso, verificar se o usuário tem permissão para fazer tal ação contra tal recurso.
- Antes de responder a requisição, fazer um filtro de saída simples baseado na permissão do usuário sobre quais dados podem ser retornados.
- Travar rotas que fazem sentido, como a
/api/v1/migrations utilizando este novo sistema.
E implementar este Sistema de Autorização terá impacto no Fluxo de Cadastro, Ativação e Autenticação de um usuário, onde para criar uma conta, ele deverá passar por estes passos:
- Criar uma conta.
- Receber um email para ativar esta conta (confirmar o email).
- Clicar no link dentro deste email, ativar a conta e receber as credenciais base.
- Conseguir criar uma nova sessão no sistema.
- E apenas com ela conseguir executar ações contra a API (nos endpoints que precisam de credencial).
Contexto
Uma plataforma como o TabNews pode se beneficiar de ter um Sistema de Autorização granular e isso significa que, ao invés de usuários terem credenciais como
AdministradorouEditorque agrupam várias sub-credenciais, seria interessante o sistema ter a possibilidade de atribuir permissões específicas e fragmentadas, diretamente associadas a cada usuário.Com isto, um usuário novo no site pode ter a permissão e credencial para criar respostas na plataforma, porém não ter a permissão para criar publicações principais (as que aparecem na Home) e só irá ganhar esta permissão após alcançar um determinado nível de engajamento. Ou no caso de um moderador ganhar o poder de editar a publicação de outros usuários, mas não ganhar a permissão de ver o email dos usuários e nem conseguir rodar as migrations do sistema.
Seja qual for o caso, um sistema mais granular se torna mais flexível e capaz de se adaptar a diferentes cenários e necessidades de segurança, permitindo uma administração mais precisa dos direitos de cada usuário.
Execução
Como descrito na seção Contexto, o sistema não deveria ser "Role-based Access Control" e deveria ser mais algo como "Resource-based Access Control".
Tudo isto deveria ser controlado pelas
featuresque um usuário possui e para na prática ter esse controle nós devemos:next-connectpara sempre injetar um usuário na requisição, seja este um usuário autenticado e com um conjunto de permissões, seja um usuário anônimo em com outro conjunto de permissões./api/v1/migrationsutilizando este novo sistema.E implementar este Sistema de Autorização terá impacto no Fluxo de Cadastro, Ativação e Autenticação de um usuário, onde para criar uma conta, ele deverá passar por estes passos: