Ações públicas em controladores administrativos


12

Descobri que na classe \Magento\Backend\App\AbstractAction(o ancestral de todas as ações do controlador administrativo) existe um membro chamado _publicActionsusado na validação da chave secreta como esta:

 if (is_array($this->_publicActions) && in_array($this->getRequest()->getActionName(), $this->_publicActions)) {
     return true;
 }

Isso significa que, se um determinado nome de ação estiver listado, _publicActionsvocê poderá acessar a ação sem a chave secreta no URL.
Essa é uma bênção para o desenvolvimento e a depuração, porque você pode fazê-lo ROOT/admin/module/controller/actionmanualmente, sem a necessidade de conhecer a chave administrativa secreta, mas o que não entendo é por que posso acessar a página de edição do produto sem a chave secreta.
Basta ligar para qualquer página de edição de produtos como esta ROOT/admin/catalog/product/edit/id/{product_id_here}.

O publicActionsmembro é substituído por pedidos (que permitem indexar e exibir), em produtos (para edição) e no controlador de redirecionamento para redirecionamentos.

Agora, minha pergunta:
por que apenas algumas ações de edição são permitidas sem a chave secreta e quando / o que devo permitir em meus módulos CRUD personalizados sem a chave secreta?

Respostas:


4

Eu nunca vi uma resposta oficial de um engenheiro do Magento sobre o assunto, mas para mim sempre pareceu que esse recurso deve ser usado quando você deseja que os usuários possam vincular a uma página de fora de uma sessão segura, caso contrário, clique em um link que faz referência a um URL de administrador seguro só o redirecionará para o painel depois de solicitar o login.

Eu sempre tive dois cenários em mente: você deseja que os usuários possam compartilhar determinadas páginas de administração com outros usuários ou deseja que uma página pública faça referência a seu URL personalizado no back-end do Magento (que, de outra forma, só redirecionaria para o painel) .

Quando você olha para o núcleo do Magento, pode ver que o Magento implementou isso essencialmente para análises, pedidos e páginas de produtos. Suponho que os engenheiros do Magento fizeram isso para que os usuários administrativos de uma loja possam enviar links diretamente por meio de um messenger ou e-mail (como em "Ei, confira este pedido: [url] ."). Certa vez, implementei um recurso como este para uma página quando queria que ele fosse facilmente compartilhável por usuários administrativos.

Você está basicamente trocando o risco aumentado de um ataque CSRF pela liberdade de poder vincular diretamente a uma página em seu back-end de administrador, o que deve ser feito apenas quando você tiver um caso de uso em mente. Suponho que as páginas CMS não se enquadram no caso de uso da equipe principal do Magento, pois elas parecem ter limitado esse "recurso" a ações relacionadas ao suporte ao cliente e à edição de produtos - basicamente as tarefas mais comuns para os representantes de atendimento ao cliente em muitos lojas.


Isso faz sentido. +1 Se eu não ouvir uma resposta oficial (diferente desta) de um membro da equipe nas próximas 24 horas, a marca de seleção é sua.
Marius

0

Se eu tivesse que adivinhar, diria que é porque a chave secreta pode ser usada como parte da proteção CSRF e / ou XSS incorporada ao Magento. Portanto, para páginas que não modificam seu conteúdo com base na entrada do usuário, pode não ser necessário ter a chave secreta.

Dito de outra forma, apenas as ações que recebem dados / entrada fornecidos pelo usuário são protegidas com uma chave secreta. Apenas um palpite.


se isso fosse verdade, a edição de uma página do CMS também deveria ser "pública". O mesmo deve editar um cliente ou uma regra tributária.
Marius

Esse é um argumento justo; e a resposta do TiEul faz sentido. Eu estava dando uma facada no escuro, parece que eu perdi.
Brett
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.