Percebo que as pessoas costumam tentar o modo de segurança sempre que algo dá errado e elas estão usando customizações de terceiros. Isso faz sentido. Você não sabe de onde vem o problema.
No entanto, o modo de segurança desabilita apenas JavaScript. Se houver algum código no lado do servidor, a solução imediata típica é descomentar todos os plugins no arquivo app.yml. Isso é aceitável, mas exige uma reconstrução e é relativamente ‘técnico’. Se você for um usuário não técnico, comentar coisas no app.yml não é algo que você leve na leveza.
Estou pensando na viabilidade de um PR que adicione a desabilitação de plugins no lado do servidor no modo de segurança. Estou imaginando algo na linha do que segue no controlador de modo de segurança.
find_opts = {
include_official: params["only_official"] != 'true',
include_unofficial: params["no_plugins"] == "true"
}
Discourse.find_plugins(find_opts).each do |plugin|
if plugin.enabled_site_setting.present?
SiteSetting.set(plugin.enabled_site_setting, false)
end
end
Sim, o mesmo efeito poderia ser alcançado se o usuário fosse até as configurações do site e desativasse os plugins dessa forma, mas percebo que os usuários raramente fazem isso.
O modo de segurança atual vale apenas para a página corrente e desaparece ao abrir uma nova aba ou atualizar a página. Portanto, é totalmente seguro para testes.
Sua proposta alteraria o significado para ativar uma configuração de forma persistente, afetando todo o site. Isso significa que também precisaria ser restrito a administradores.
Entendo sua proposta, mas representa uma grande mudança no comportamento.
Acho que o ponto principal é que administradores de sites não técnicos buscam uma solução para fazer o site funcionar quando está quebrado. Um “Modo de segurança” é frequentemente percebido como capaz de fazer isso (correta ou incorretamente). Talvez uma maneira de fazer isso fosse ter controles adicionais de modo de segurança para administradores.
Você poderia adicionar um botão grande na rota /admin/plugins para desabilitar automaticamente todos os plugins da mesma maneira; no entanto, me pergunto se teria o mesmo efeito. Talvez tivesse.
Também sou atraído por essa ideia, pois é bastante viável dentro da arquitetura atual de plugins do Discourse.
Normalmente, o que quebra plugins são alterações incompatíveis no núcleo; muitas vezes, o sistema nem sequer inicia se você incluir um plugin problemático ou durante a inicialização.
Um recurso para desativar todos os plugins teria que reiniciar o aplicativo de alguma forma para funcionar corretamente.
Acho que eu estaria aberto a uma alteração no plugin de gerenciamento do Docker que permitisse desativar/ativar plugins facilmente, movendo arquivos para dentro e para fora do diretório de plugins e reiniciando o aplicativo. Isso poderia acelerar a depuração.
No entanto, noto que um número considerável de erros provém de código envolvido na API de plugins do lado do servidor, o que seria tratado por isso (acho que sim?).
Atualmente, o “modo seguro” (ou algo similar) não é uma solução completa para problemas de quebra. Adicionar uma desativação automática de plugins tornaria a solução um pouco melhor, reduzindo o número de casos em que é necessário um reinício completo ou alteração de configuração, e refletindo melhor como administradores de sites não técnicos enxergam a situação.
Acho que estou buscando passos incrementais e relativamente fáceis. Talvez a mudança no gerenciador do Docker seja igualmente direta do ponto de vista técnico.
Sim, se possível algum dia, seria muito bom ter um único booleano “desativar todos os plugins” nas configurações de administração, que funcione sem necessidade de reconstruir nenhum container. No entanto, não sendo um desenvolvedor do Discourse (tendo apenas um ano de experiência com desenvolvimento de apps em node.js e vuejs), meus instintos me dizem que essa não é uma mudança simples e seria uma alteração muito grande na arquitetura.
Nosso fórum legado em LAMP tinha esse recurso e não conseguimos contar quantas vezes usamos esse booleano para identificar rapidamente se um erro estava relacionado a plugins. No entanto, a arquitetura do software é tão diferente que nem vale a pena comparar.
Estou pessoalmente confiante de que a equipe do Discourse encontrará uma solução. Muitos usuários são viciados em plugins e haverá mais desafios ao longo do tempo.
Um fator importante para mim é que esse recurso seria 100% voltado para quem faz auto-hospedagem. Não tenho grande interesse em manter um modo de segurança para plugins no núcleo, pois certamente não é algo que usaríamos; coordenar uma reinicialização em 5 clusters é difícil.
O Docker Manager é a solução adequada aqui. Ele já suporta a reinicialização do aplicativo, algo necessário para que sua proposta funcione, e pode realizar todas as tarefas necessárias sem alterações no núcleo do Discourse.