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.
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 ...
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.
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)
"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.
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?
@@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
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.
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.
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?
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.
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)
É 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
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.
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?
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.
Respeito a tua visão, mas há questões a se observar: acoplamento, versionamento, bater no banco se resolve com cache facilmente. Se tiver qualquer forma de pagamento ou transferência de valores já não é viável. Resumindo: pra MVC é uma boa escolha, mas a partir do momento que entrou em produção, não ter essas estruturas é quase certeza de débito técnico no futuro!
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?
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.
@@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
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.
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
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...
@@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
@@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.
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.
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.
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.
To acompanhando a série, qualidade pura
Concordo, mas a partir do momento que um user pode ter N roles no banco, obrigatoriamente vai passar a existir uma tabela roles.
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 ...
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.
@@luanrodrigues4901 Concordo, eu faria/faço da mesma forma
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!
Não pareceu piada...
Ó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.
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)
@@joaorodrs não há problema em ter uma tabela.
Acho que seria bom para a segurança ter testes unitários e reviews das permissões
@@joaorodrs Mas usando seeders não acaba entrando no mesmo problema de performance que ele apontou?
"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.
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?
@@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
Eu so colocaria um double check na api. Pq se um hacker alterar o front , ele vira admin
Concordo, pois qualquer um que pegar a requisição pode consumir sem passar pelo front e burlar alguma regra de negócio
Acho que todas ideias que ele passou no vídeo são referentes ao backend mesmo
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.
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.
@@TheGusMP não por completo, você tem que fazer segurança que até um desenvolvedor que saiba das informações não consiga burlar
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?
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.
Criar roles faz sentido, mas criar permissions não. O código precisa "suportar" essa nova permissão
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)
É 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
Exato! E pode colocar em cache pra uso em toda a aplicação!
pergunta: não seria mais facil usar um enum indicando na tabela de user qual o papel dele no sistema?
Depende o banco usado, não existem enums.
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.
caraca diegao, que aula meu amigo..
meu mano, vejo que voce coda na velocidade da luz, estou bastante intrigado com que teclado voce trabalha. Pode mostrar pra gente?
Bom dia Diego! Onde encontro essa aula completa?
Onde essas lives acontecem? gostaria de acompanhar
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?
sim, é comum botarem a role no token
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.
Respeito a tua visão, mas há questões a se observar: acoplamento, versionamento, bater no banco se resolve com cache facilmente. Se tiver qualquer forma de pagamento ou transferência de valores já não é viável.
Resumindo: pra MVC é uma boa escolha, mas a partir do momento que entrou em produção, não ter essas estruturas é quase certeza de débito técnico no futuro!
Essa validacao no codigo nao daria brecha pro usuario editar o codigo pelo F12 e permitir algo pelo qual nao teria acesso?
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.
Exatamente como implementei na empresa, atribuindo as permissões aos papéis diretamente no código.
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?
Continua sendo RBAC, mas é algo mais específico, geralmente não vemos isso de forma comum nas aplicações.
Qual tema é esse do VSCODE ?
Opa, acho que seria legal um vídeo atualizado de folder structure!
Eu usaria CASL tanto no front quanto no Back. Fica mais semântico de entender com essa lib.
É o que estou usando :)
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
Em uma arquitetura de micro serviço de autenticação? Como ficaria? (SSO)
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.
@@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
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.
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
É disso que eu to falando, a galera quer fazer coisa mais complexa do que precisa
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...
@@UmaTagPorDiamano, assista novamente 😂
@@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
@@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.
incrível!
leram a minha mente, tava pesquisando sobre isso
Qual é o site que usa para fazer os diagramas?
tldraw
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.
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
Alguma vez pensou em usar Keycloak?
Já usei, mas Keycloak é incrível em funcionalidades, péssimo em customização.
Entre varios identity providers como o firebase auth, aws cognito e keycloak, qual ce acha melhor?
Que app é esse que está sendo usando para apresentar?
É um site/extensão chamado tldraw
Não conheço, mas acho que é "tldraw"
Só não gostei de finalizar usando um array, usar um bitfield seria bem mais performático. Acho que vale mostrar isso aí pessoal!
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.
o que vcs acham de cache, devo implementar cache em todas aplicacoes do backend
Viva a gambiarra😂
Que bizarro, depender do próprio código pra criar permissões. Com certeza o stripe não faz assim kkkk
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.
cv programmer top br abraço tmj
da pra ver diego q vc nao dorme muito deveria descansar mais ta fazendo mal isso