Публичные действия в административных контроллерах


12

Я обнаружил, что в классе \Magento\Backend\App\AbstractAction(предке каждого действия контроллера администратора) есть член с именем, _publicActionsкоторый используется для проверки секретного ключа, например:

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

Это означает, что если в списке указано определенное имя действия, _publicActionsвы можете получить доступ к действию без секретного ключа в URL.
Это благословение для разработки и отладки, потому что вы можете просто сделать это как ROOT/admin/module/controller/actionвручную, без необходимости знать секретный ключ администратора, но я не понимаю, почему я могу получить доступ к странице редактирования продукта без секретного ключа.
Просто позвоните на любой странице редактирования продукта, как это ROOT/admin/catalog/product/edit/id/{product_id_here}.

Элемент publicActionsперезаписывается для заказов (которые позволяют индексировать и просматривать), в продуктах (для редактирования) и в контроллере перенаправления для перенаправлений.

Теперь мой вопрос:
почему только некоторые действия по редактированию разрешены без секретного ключа, и когда / что я должен разрешить в своих пользовательских модулях CRUD без секретного ключа?

Ответы:


4

Я никогда не видел официального ответа от инженера Magento по этому вопросу, но мне всегда казалось, что эта функция должна использоваться, когда вы хотите, чтобы пользователи могли ссылаться на страницу из-за пределов безопасного сеанса, в противном случае нажмите на ссылка, ссылающаяся на защищенный URL-адрес администратора, перенаправит вас на панель мониторинга только после запроса на вход в систему.

Я всегда имел в виду два сценария: либо вы хотите, чтобы пользователи могли обмениваться определенными административными страницами с другими пользователями, либо вы хотите, чтобы какая-либо общедоступная страница ссылалась на ваш пользовательский URL-адрес в бэкэнде Magento (который в противном случае перенаправлял бы только на панель инструментов) ,

Когда вы посмотрите на ядро ​​Magento, вы увидите, что Magento по сути реализовал это для обзоров, заказов и страниц с продуктами. Я предполагаю, что инженеры Magento сделали это так, чтобы пользователи-администраторы магазина могли отправлять ссылки напрямую через мессенджер или по электронной почте (как в «Эй, проверьте этот порядок: [url] .»). Однажды я реализовал такую ​​функцию для этой страницы, когда хотел, чтобы ее легко могли использовать администраторы.

В основном вы торгуете повышенным риском атаки CSRF за свободу иметь возможность напрямую ссылаться на страницу в бэк-энде администратора, что следует делать только тогда, когда у вас есть очень определенный сценарий использования. Я полагаю, что CMS Pages не попали в сценарий использования для основной команды Magento, так как они, по-видимому, ограничивали эту «функцию» действиями, связанными с поддержкой клиентов и редактированием продуктов - в основном наиболее распространенными задачами для представителей обслуживания клиентов во многих магазины.


Это имеет смысл. +1 Если я не услышу официальный ответ (отличный от этого) от члена команды в течение следующих 24 часов, отметка будет вашей.
Мариус

0

Если бы мне пришлось делать предположения, я бы сказал, что это потому, что секретный ключ может использоваться как часть защиты CSRF и / или XSS, встроенной в Magento. Так что для страниц, которые не изменяют свое содержимое на основе пользовательского ввода, может быть необязательно иметь там секретный ключ.

Другими словами, только действия, которые получают пользовательские данные / ввод, защищены секретным ключом. Просто предположение.


если это правда, то редактирование страницы CMS также должно быть «общедоступным». Так следует редактировать клиента или налоговое правило.
Мариус

Это справедливо; и ответ TiEul имеет смысл. Я получал удар в темноте, похоже, я пропустил.
Бретт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.