Executando verificação de segurança...
2

[TabNews] Entendendo método de autorização

Olá, comunidade!

Estou estudando o repositório do TabNews para aprender com as boas práticas e também para implementá-las no meu código.

Continuando a saga iniciada aqui: https://www.tabnews.com.br/Galdino/duvida-porque-nao-usamos-orms-no-tabnews

Autorização

Gostaria de entender melhor uma escolha feita no modelo de autorização. Não tenho certeza se é uma questão de segurança ou se foi uma decisão consciente.

No modelo de autorização, há uma função chamada can que valida as permissões dos usuários. No entanto, essa validação é feita com base em informações armazenadas no LocalStorage, o que pode ser facilmente editável.

Dúvidas

Essa escolha foi feita porque as permissões editáveis não afetam diretamente a plataforma?
Essa abordagem é considerada uma boa prática?
Seria uma alternativa mais segura usar as permissões em um token JWT?

Agradeço antecipadamente por qualquer esclarecimento sobre essas dúvidas.

Carregando publicação patrocinada...
4

Galdino, show de bola meu caro! Seja muito bem vindo nos estudos da plataforma 🤝

No modelo de autorização, há uma função chamada can que valida as permissões dos usuários.

Correto, se trata desta função aqui.

No entanto, essa validação é feita com base em informações armazenadas no LocalStorage, o que pode ser facilmente editável.

A validação não é feita com base em informações armazenadas em LocalStorage, pois como você especulou, se este fosse o caso, seria facilmente editável.

O que você encontrou no LocalStorage é um array de features que são usados pelo frontend para a interface decidir mostrar ou não alguns recursos (por exemplo, recursos de moderação). Nenhuma destas informações são retornadas para o backend e o único fluxo neste caso é de mão única do backend para o frontend.

Então a confusão na sua avaliação pode ter acontecido porque este é o mesmo array que fica no backend, mas lá ele não é editável. Então o método authorization#can é usado apenas no backend da aplicação e que busca as informações que estão no banco de dados.

O método de autenticação + autorização que usamos é session based e difere de estratégias stateless como o JWT. E como tudo em tecnologia, uma solução não é melhor que a outra, é uma questão de contexto e tradeoff 🤝

2

Interessante isso em, to aprendendo muito aqui no tabnews , absorvendo muita coisa e tentando mostrar o que eu sei para as pessoas, sobre backend node ou baseados em java eu nao entendo muito. Mas achei interessante esse tipo de autenticação, vou procurar saber mais sobre, o JWT, sei que utiliza-se de token e refresh porem o session bases nunca tinha visto.
não

Curso do Filipe (curso.dev)

Comprem, é incrível, nao me arrependo um segundo, eu sou um cara muito ansioso, quero consumir varios assuntos ao mesmo tempo, e as aulas do curso.dev me faz querer acompanhar igual acompanhava supernatural a uns dez anos atrás, um episódio por semana, mas estou aprendendo muito sobre os conceitos e ta me deixando mais calmo, comprei alguns cursos mas sem didática nenhuma, a pessoa só ia programando e eu sem saber nada, no curso.dev é ao contrário, la você monta etapa por etapa, você monta varios quebras cabeça que antigamente não se juntavam.
Ancioso pra um dia poder contribuir no TabNews.

2

Vou responder o que eu sei, já que nada sei sobre o Tabnews em si.

Essa escolha foi feita porque as permissões editáveis não afetam diretamente a plataforma?

Espero que sim.

Existe uma máxima (algumas pessoas chamam de boa prática) que tudo o que for fazer no servidor deve ser validado nele. Não deve confiar em nada que está do lado do cliente, a não ser algo que só afete o cliente.

Então se só afeta o cliente, está tudo bem.

Se pega do cliente para facilitar, mas no momento que vai fazer algo importante no servidor a autorização é dada lá, e o que está no cliente não é levado em consideração, ou seja, se você modificar na mão, não importa, não será usado no servidor para te dar alguma autorização de acesso lá.

Isso me lembra as pessoas querendo disfarçar o id de um item que está no banco de dados para ninguém modificar o que não pode. Mas isso não protege nada. Pode até ficar mais difícil descobrir um id válido, mas se achar, fará o estrago. Isso chama-se segurança por obscuridade, que pode ser usada em conjunto outra melhor, mas nunca sozinha, e em alguns casos não faz sentido nem junta. Então você pode usar o id mais simples que puder, só cuide para que a autorização seja efetiva, ou seja, antes de fazer qualquer ação, mínima que seja, você verifique se quem pediu para fazer tem autorização para fazer isso. A forma de fazer pode variar, mas deve ser uma forma segura.

Essa abordagem é considerada uma boa prática?

Eu sempre explico que "boa prática" é uma regra que alguém inventou para empurrar para outras pessoas o que ela não quer explicar. Pode ser bom ou não, a explicação daria uma informação melhor. Se tiver uma boa explicação então passar ser conhecimento e não é mais "boa prática".

Se não causa problemas, é uma prática adequada. Se causa, claramente é uma prática errada. Então não importa se é boa prática ou não, importa se funciona corretamente, atendendo todas as necessidades, neste casos, em especial, de segurança. Também pode envolver UX ou otimização. Portanto se essa autorização só afeta o cliente ou se afetar o servidor é feito uma autorização lá, e tem a informação redundante no cliente só para facilitar para ele, quem sabe para melhorar a experiência do usuário, ou diminuir os acesso ao servidor, então está tudo bem, é algo que poderia ser recomendado.

Seria uma alternativa mais segura usar as permissões em um token JWT?

Pelo que está descrevendo não há ligação, você só precisaria de algum token para manter a conversa com o servidor autenticada. Qualquer forma de token tem uma informação para que suas comunicações possuam uma assinatura, uma forma de verificar que partiram de você que já foi autenticado antes. Não é para ter uma informação de autorização (até pode existir em ambientes que você confia na outra parte, o que quase nunca deveria acontecer, até porque não costuma ter vantagem em fazer isso).

Faz sentido para você?

Espero ter ajudado.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

1

de certo tem alguma checagem tambem no backend se seu usuário realmente pode faz a ação.
não é boa prática simplesmente confiar no que veio do cliente, por ex, mesmo que no frontend vc já validou usando javascript que um campo é do tipo "endereço de email" no backend essa checagem será feita novamente.

1