Como EU lido com autorizações (permissões) nos meus apps

[@vibedev.official]

Show de bola Diegão, segunda-feira criamos um Micro-SaaS do zero e usamos estes conceito. Bem mais simples de gerir! Meu canal tem uma série ensinando a cria Micro-SaaS.

[@martinsdev]

To acompanhando a série, qualidade pura

[@viniciusnovais74]

Vai parecer piada mas estava fazendo um App em Rails e chegou nessa parte de permissões esse video me deu um bom norte obrigado!

[@danton_Yn]

Não pareceu piada...

[@marceloroldrin]

Ótimo conteúdo. Gostei da segunda solução. Só que eu teria uma tabela sim para "permissions". Imagina, a cada regra, ter que ir no código mudar.

[@joaorodrs]

Realmente um trabalho enjoado, mas isso seria o mesmo pra caso tivesse uma tabela de "permissions" não? A diferença é que seriam feitas seeders (a não ser que o front tenha a feature de editar as permissões de cada role)

[@marceloroldrin]

@@joaorodrs não há problema em ter uma tabela.

[@LucasAlmeida-ef9io]

Acho que seria bom para a segurança ter testes unitários e reviews das permissões

[@LucasAlmeida-ef9io]

​@@joaorodrs Mas usando seeders não acaba entrando no mesmo problema de performance que ele apontou?

[@luanfelipecosta]

"A beleza da complexidade está na simplicidade" Parabens diego, ser ENGENHEIRO DE SOFTWARE é isso aí, a habilidade de tornar problemas complexos em coisas simples. Escrever código e usar frameworks é a parte mais fácil do job. De novo caimos no princípio de pareto. Esses 20% de tempo fazendo um bom planejamento representam 80% do valor, e os outros 80% de templo implementando correspondem a 20% do valor.

[@UmaTagPorDia]

Se tu for um Dev é sim super simples, agora experimenta criar um sistema que uma.pessoa "normal" vai gerir... Vai realmente esperar que ela abra o código caso preciso adicionar ou alterar essas rolês padrões?

[@silasbispo01]

@@UmaTagPorDia se você está prevendo essa necessidade então faça da forma necessária ué, a questão é não criar uma solução complexa pra um problema que dá pra resolver com uma solução simples

[@teliiz]

caraca diegao, que aula meu amigo..

[@adailsonmoreira9978]

Eu concordo com o Diego, algo que ainda tenho dúvidas de como organizar é como fazer visualização personalizada tanto na saída quanto na consulta a api exemplo eu tenho um manager que a partir da empresa que ele tá ele vai trazer coisas só da empresa dele na consulta a API (ficar fazendo ifs vai tornar isso gigante) nunca consegui pensar numa arquitetura pra isso ...

[@luanrodrigues4901]

Vc cria um endpoint da API que recebe um “path pram” GET /empresa//funcionarios Dessa forma é possível pegar o da empresa através da URL. No controller do endpoint vc vai fazer uma consulta simples no banco de dados: Select * from funcionários where empresa_id = 😊 espero ter ajudado.

[@esbnet]

É possível também criar uma variável global "ROLE" e carregar do banco no login do usuário. Dessa forma fica até mais rápido porque já está na memória e nem precisará buscar do arquivo. Ou então, configura as roles no arquivo e carrega para uma variável global na inicialização do projeto. Pensando melhor... acho que foi essa segunda opção que o Diego falou... srsrsr

[@PedroHenrique-jy2dg]

Concordo, mas a partir do momento que um user pode ter N roles no banco, obrigatoriamente vai passar a existir uma tabela roles.

[@cleristonmartinscardoso2557]

meu mano, vejo que voce coda na velocidade da luz, estou bastante intrigado com que teclado voce trabalha. Pode mostrar pra gente?

[@EuSouAnonimoCara]

Exatamente como implementei na empresa, atribuindo as permissões aos papéis diretamente no código.

[@LewisSenpai]

Valeu Diego. Mas fiquei com uma duvida Usando essa estrategia, ja que a ideia é reduzir as consultas a BD em cada request do usuário, seria adequado essa role ja vir no token que vem do frontend para verificar a role do usuário ou seria melhor ter apenas o id, fazer uma consulta a BD e ai verificar a role?

[@jaciroscar]

sim, é comum botarem a role no token

[@Jeferson-l6d]

leram a minha mente, tava pesquisando sobre isso

[@ojoaoalexandre]

Bom dia Diego! Onde encontro essa aula completa?

[@vandsonfalcao]

Se as permissoes vao ficar no codigo, ficaria no codigo de quem front-end ou backend? colocar em apenas um serviço posibilita usar o outro servico independente das permissoes. se colocar no frontend como o backend iria verificar o lance de permissao? consultando o front? ai iriamos cair na precisao de uma requisicao para consultar roles. ficou esse furo na historia diegao.

[@kalilaziz8591]

Onde essas lives acontecem? gostaria de acompanhar

[@UmaTagPorDia]

Tu não pode criar, mas o ADM master que gerencia todo o clister de dados pode, então pensando que numa reunião alguém define que precisam de novas roles, seria gasto de tempo fazer deploy de uma nova versão do arquivo. A menos que se trabalhe com escrita de arquivo estático. Em um SaaS tu é um ADM do seu contexto, mas tem um user root que geralmente tem acesso a todos os contextos. Já pensou se eu for o user root e adicionar permissão de criar rolês pro seu usuário?

[@rodrigodmpa]

Penso diferente. Por ser algo que envolve segurança, é importante ter uma certa dificuldade de ser feito. Até para rastreamento e governança. Se teve alguma mudança em permissões de uma role, isso fica registrado em um commit. Além disso, na minha visão esse tipo de operação é rara de acontecer. Não acho que seja necessário criar roles todo mês por exemplo.

[@souzaramon9522]

Criar roles faz sentido, mas criar permissions não. O código precisa "suportar" essa nova permissão

[@LucasAlmeida-ef9io]

Concordo com o Rodrigo. Adiciono que acredito que o Diego não está supondo a existência de um root capaz de criar novas roles e permissions (e sim, gerenciar as existentes)

[@pedro-canedo]

É disso que eu to falando, a galera quer fazer coisa mais complexa do que precisa

[@UmaTagPorDia]

Queria saber quando ficou mais fácil editar o código do que ter uma interface para gerenciar uma tabela... A menos que faça sua interface gravar/ler o arquivo, mas aí tu entra em problemas de R/W, concorrência no arquivo, principalmente em SaaS onde tu de repente tem 100k de usuários lendo e escrevendo no arquivo. A engine dos bancos já prevê isso...

[@silasbispo01]

@@UmaTagPorDiamano, assista novamente 😂

[@LucasAlmeida-ef9io]

​​@@UmaTagPorDia Acho que vc não entendeu a proposta: o arquivo permissions.ts declara permissões constantes, que só vão subir para produção quando houver uma release. Não necessariamente fica mais fácil alterar as permissões, mas tem outras vantagens

[@LucasAlmeida-ef9io]

​​@@UmaTagPorDia Ele tá falando de editar as roles e permissões no código e subir pra produção nas releases. Não necessariamente é mais fácil de gerenciar, mas traz vantagens de performance e segurança, além de deixar a complexidade do sistema mais simples no geral.

[@vini1520]

Eu so colocaria um double check na api. Pq se um hacker alterar o front , ele vira admin

[@danielcamposdev]

Concordo, pois qualquer um que pegar a requisição pode consumir sem passar pelo front e burlar alguma regra de negócio

[@LucasAlmeida-ef9io]

Acho que todas ideias que ele passou no vídeo são referentes ao backend mesmo

[@dieegosf]

Com certeza, mesmo estando no código, isso tem que ser validado tanto na API quanto no front-end! Se for criar um projeto full-stack JavaScript, você pode compartilhar o pacote de permissões entre os dois ambientes, caso contrário, pode optar por uma linguagem como JSON ou YAML para gerir as permissões.

[@TheGusMP]

Sim, uma API key resolveria esse problema: tem a API key correta? Se sim, prossegue, senão retorna erro. Essa lógica até poderia estar numa espécie de midleware.

[@vini1520]

@@TheGusMP não por completo, você tem que fazer segurança que até um desenvolvedor que saiba das informações não consiga burlar

[@niltonschumacherfilho3368]

Opa, acho que seria legal um vídeo atualizado de folder structure!

[@andeerdacampo_dev]

Eu já criei um projeto onde o admin podia criar as roles e personalizar todas as permissions de cada role, isso sim era enjoado kkk

[@moronipereira1649]

Essa validacao no codigo nao daria brecha pro usuario editar o codigo pelo F12 e permitir algo pelo qual nao teria acesso?

[@ramonbsales]

Provavelmente, esse arquivo deve ficar no servidor e não no cliente. Dessa forma, o usuário não teria acesso a ele via F12.

[@adrielschmitz]

Rapaz, tá na hora do Diego se atualizar... o github dele ainda está com o 3g, já estamos quase indo pro 6g na vida real.

[@entrepreneurdrive]

Eu usaria CASL tanto no front quanto no Back. Fica mais semântico de entender com essa lib.

[@dieegosf]

É o que estou usando :)

[@thalesedu1372]

pergunta: não seria mais facil usar um enum indicando na tabela de user qual o papel dele no sistema?

[@dieegosf]

Depende o banco usado, não existem enums.

[@AndreLuiz-fy3ll]

No exemplo dele a Role tá em Membership porque em cada time você pode ter uma Role diferente. A Role da entidade do seu usuário vai ser guardada na tabela referente ao seu usuário mesmo.

[@matheusroberto8158]

Qual tema é esse do VSCODE ?

[@gabriel.pessoa]

e no caso de um usuário poder ter tanto uma role, quanto uma permissão específica para aquele usuário? por exemplo, o usuário tem a role "member" padrão, mas eu querer adicionar uma permission para aquele usuário sem ter que alterar a role ou criar uma nova, que tipo de autorização é essa?

[@dieegosf]

Continua sendo RBAC, mas é algo mais específico, geralmente não vemos isso de forma comum nas aplicações.

[@augustofernandesmarsola9284]

incrível!

[@jogadorum7572]

sim, qm nunca penou pra decidir lógica de autorização, eu já penei muito. E sim, elas poderiam ter sido resolvidas de maneiras mais fáceis

[@xavierjece_oficial]

Qual é o site que usa para fazer os diagramas?

[@dieegosf]

tldraw

[@orafael5744]

Em uma arquitetura de micro serviço de autenticação? Como ficaria? (SSO)

[@Mattias439]

nem me fale nisso cara, o raiva é essa historia de SSO, eu fiz um aparatir de uma lib, tentando fazer a comunicação como micro serviço e está insurpotavel.

[@orafael5744]

@@Mattias439 na empresa onde atuo, tem um SSO em funcionamento autenticar as aplicações internas, agora só estou buscando formas de melhorar a parte de autorização

[@LucasAlmeida-ef9io]

Acredito que boa parte do que ele propôs ficaria idêntico no caso de um sistema com suporte a SSO. Se estiver usando SAML, vc tem o serviço de autenticação separado. Usando SCIM, vc sincronizaria os usuários e times do diretório com os usuários e times do seu banco de dados, com provavelmente informações adicionais específicas da sua aplicação. A parte do "Membership" e "permissions.ts" da solução proposta seria mantida.

[@henriquedelben]

Poderia pegar os roles direto do JWT/JWS, supondo q vc esta usando OAuth. O JWS validando sua assinatura já deixa subentendido que os roles estão corretos ent vc pega as roles do jwt e seta em algum tipo de variável compartilhada durante o processamento do pedido do cliente Pelo menos assim é a forma padrão com q o Spring em java lida c/ spring security

[@markfazolin]

Só não gostei de finalizar usando um array, usar um bitfield seria bem mais performático. Acho que vale mostrar isso aí pessoal!

[@dieegosf]

Cada banco tem suas diferentes formas de armazenar esse tipo de informação, acho que o array fica mais educacional e, então depois, para otimização, a pessoa pode buscar outras opções.

[@oscarrafaelcampos]

Alguma vez pensou em usar Keycloak?

[@dieegosf]

Já usei, mas Keycloak é incrível em funcionalidades, péssimo em customização.

[@henriquedelben]

Entre varios identity providers como o firebase auth, aws cognito e keycloak, qual ce acha melhor?

[@felipemoraes3957]

Que app é esse que está sendo usando para apresentar?

[@fire_fisT]

É um site/extensão chamado tldraw

[@LucasAlmeida-ef9io]

Não conheço, mas acho que é "tldraw"

[@tav1119]

Viva a gambiarra😂

[@PatricioPatrick-z2q]

o que vcs acham de cache, devo implementar cache em todas aplicacoes do backend

[@riseunk0]

Que bizarro, depender do próprio código pra criar permissões. Com certeza o stripe não faz assim kkkk

[@dieegosf]

Nada adianta "depender" do banco de dados e o mesmo ser alimentado via seed que vem do próprio código, é justamente o que muita aplicação faz e no fim das contas o código é quem está determinando os cargos e permissões.

[@cvclasher8033]

cv programmer top br abraço tmj

[@DailyNewsInternationalShorts]

da pra ver diego q vc nao dorme muito deveria descansar mais ta fazendo mal isso