Tenho trabalhado em segurança lógica com base nas informações do usuário atual, como if this.topic.creator.username === User.current().username, para permitir que o usuário edite ou exclua o tópico.
O ponto é: preciso garantir certas ações com base na sessão do usuário! Mas tenho feito alguns testes e é por isso que estou aqui perguntando a vocês.
Através do JavaScript no navegador (mesmo em modo de produção), é possível executar Discourse.User.current().set('username', 'sometestename'). Dessa forma, algumas ações no meu sistema seriam habilitadas apenas com essa alteração. Sei que esse não é o objetivo de 99% dos usuários, mas, além desse caso, vocês conhecem alguma maneira de garantir que o usuário não manipule as informações dele?
Se você alterar informações no seu navegador local, isso não muda nada no back-end.
O usuário está logado por meio de um token de autenticação, creio eu, então você não pode se passar por outra pessoa para o back-end:
Como não é possível enganar o servidor, você não conseguirá fazer nenhuma alteração como outro usuário.
Assim que você atualizar o navegador, suas alterações locais provavelmente serão apagadas. No pior caso, você provavelmente vai corromper o estado da aplicação JavaScript e terá que limpar o cache.
Como você disse, a melhor maneira seria sempre obter a sessão do usuário atual no servidor back-end.
Dessa forma, as alterações de cache no navegador não teriam efeito! Você sabe onde posso verificar se a segurança lógica é baseada na sessão do usuário no servidor back-end e não no PreloadStore?
Me avise se eu estiver seguindo o caminho errado! Obrigado, Robert, pela ajuda!
Não sou especialista em segurança, apenas desenvolvedor de aplicativos, mas todas as alterações persistentes só podem ser feitas no servidor. O que acontece no navegador no EmberJS é para conveniência do usuário e uma experiência de usabilidade superior, como cache para velocidade e comportamento de interface semelhante ao de um aplicativo, quase automático. Isso não muda o fato de que, em última análise, ele precisa negociar todas as alterações persistentes com o servidor Rails e, ao fazê-lo, terá permissão para isso apenas para o usuário logado.
O mesmo vale para toda a recuperação de dados: o servidor Rails só enviará dados aos quais o usuário logado tem acesso.
Acho que você não precisa se preocupar com isso, porque, se alguém tentasse subverter isso, esbarraria no primeiro obstáculo: não há como enganar a API.
Estou preocupado porque estou trabalhando em algumas abordagens em que tal ação estará disponível ou não dependendo do seu usuário: se você é o criador do tópico, se é o criador da postagem. Assim, preciso validar com base na sessão do usuário no backend.
Como isso, na postagem, o usuário pode editá-la se for o criador da postagem.
EDIT: Como as permissões de postagem do Discourse, vou verificar.
Tenho analisado o código do plugin e a base de código sobre controles de post (ações), para verificar em quais pontos posso agir mais fortemente em termos de segurança.
Conforme analisado! No front-end, existem algumas etapas que verificam se o usuário pode ou não editar o post, como:
