Отказано в доступе после установки SUPEE-6285

85

После установки исправления SUPEE-6285 в нашем магазине Magento 1.7.0.2 система выдает ошибку « Отказано в доступе » при попытке получить доступ ко всем настраиваемым модулям для пользователей, которые имеют выборочные разрешения (не все разрешения). Снимок экрана ниже.

введите описание изображения здесь

Полномочия пользователя правильно установлены в ресурсах ролей, и мы повторно применили настройки разрешений, чтобы убедиться, что они установлены.

Эта проблема была воспроизведена для нескольких пользовательских расширений, поэтому не работает только одно расширение.

Я вышел из системы, очистил кеш и подтвердил, что компилятор отключен.

Кто-нибудь может подсказать, как решить эту проблему?

admin security patches acl supee-6285 Крис
источник

Ответы:

129

Как написано здесь :

Если вы используете ограниченные учетные записи администратора, некоторые меню сторонних расширений могут больше не работать для них. Причина в том, что возвращаемое значение по умолчанию Mage_Adminhtml_Controller_Action::_isAllowed()было изменено с trueна Mage::getSingleton('admin/session')->isAllowed('admin'). Расширения, которые не переопределяют этот метод в своих административных контроллерах, поскольку они не используют ACL, теперь нуждаются в привилегии «ALL» .

Единственное решение - это исправить патчи и добавить этот метод ко всем их контроллерам администратора:

protected function _isAllowed()
{
    return true;
}

Или если у них действительно есть ресурс ACL, определенный в etc/adminhtml.xml:

protected function _isAllowed()
{
    return Mage::getSingleton('admin/session')->isAllowed('ENTER RESOURCE IDENTIFIER HERE');
}

Как определить идентификатор ресурса

Вот как adminhtml.xmlможет выглядеть:

Пример Mage_Setup (acl)

Возьмите имена узлов ниже acl/resources/admin/children, пропуская следующие childrenузлы.

Как создать отсутствующие идентификаторы ресурса

Если есть только <menu>определение, но нет <acl>определения, вы также можете определить свое собственное (оно не обязательно должно быть в одном модуле, поэтому не нужно изменять файлы сторонних производителей):

Пример Mage_Setup (меню)

Скопируйте все ниже , menuчтобы acl/resources/admin/childrenи удалить <action>узлы.

Автоматическое исправление

Есть хороший инструмент командной строки от SupportDesk.nu по адресу https://gist.github.com/raybogman/eec47237b8ef0d4dd0fd

Он _isAllowed()хорошо обрабатывает большинство пропущенных вызовов, но приводит к некорректному коду с обфусцированными или зашифрованными исходными файлами, поэтому вам все равно следует проверить результаты вручную.

Фабиан Шменглер
источник
Только что протестировал это решение, и предоставление разрешения «Dashboard» не имеет значения. Является ли «привилегия Dashboard» тем же, что и разрешение «Dashboard» в Role Resources, или это где-то еще?
Крис
2
Обновленный ответ, я неверно истолковал конфигурацию для admin, он на самом деле возвращает только true для пользователей со всеми привилегиями.
Фабиан Шменглер
3
Пожалуйста, не делайте, return true;если в вашем config.xmlили adminhtml.xml. Ничего не определено для ACL . Вместо этого добавьте права доступа к файлу xml и проверьте его правильно. Взгляните на сайт Alan Storm или здесь для получения информации о создании разрешений.
Кел
Это нормально работает для пользовательского модуля, но если есть раздел для настройки конфигурации, как мы можем дать доступ к этому блоку?
mjdevloper
1
Контроллеры для маршрутов, которые настроены с <use>admin</use>. Они обычно расширяются Mage_Adminhtml_Controller_Action.
Фабиан Шменглер
2

В моем случае для сторонних модулей добавление приведенного ниже кода в контроллеры adminhtml работало:

protected function _isAllowed()

{
     return true;
}
Анкур Джайн
источник
-5

Так должно быть:

protected function _isAllowed()
{
    return Mage::getSingleton('admin/session')->isAllowed('system/config');
}

В этом случае он возвращает настройки ACL от Magento. Мне просто интересно, исправит ли Magento Core Team это с другим патчем или это нужно сделать в app / code / local как глобальное исправление ...

Петр Сейчук
источник
3
Это не предполагаемое поведение. Они специально сделали ограничения для администраторов по умолчанию. Так что на самом деле производители расширений вынуждены обновлять сейчас.
Фабиан Шменглер
1
Так что, да, если это работает для вас, исправьте это app/code/local, но показывать пользовательские расширения без ACL тогда и только тогда, когда у пользователя есть разрешения, System > Configurationне то, что когда-либо хотелось бы.
Фабиан Шменглер
Ваше решение является обходным путем и не рекомендуется! Вы можете вернуть true по умолчанию (как это было в административном контроллере до этого патча). Лучшее решение: правильно настроить списки контроля доступа.
Матиас Кляйн