Errores de acceso denegado después de instalar SUPEE-6285

85

Después de instalar el parche SUPEE-6285 en nuestra tienda Magento 1.7.0.2, el sistema muestra un error de " Acceso denegado " al intentar acceder a todos los módulos personalizados para usuarios que tienen permisos selectivos (no todos los permisos). Captura de pantalla a continuación.

ingrese la descripción de la imagen aquí

Los permisos de usuario se establecen correctamente en Role Resources y hemos vuelto a aplicar la configuración de permisos para garantizar que se establezcan.

El problema se ha reproducido en varias extensiones personalizadas, por lo que no es solo una extensión que no funciona.

He cerrado / cerrado sesión, borrado el caché y confirmado que el compilador está desactivado.

¿Alguien puede sugerir cómo solucionar esto?

Chris
fuente

Respuestas:

129

Como está escrito aquí :

Si usa cuentas de administrador restringidas, es posible que algunos menús de extensiones de terceros ya no funcionen para ellas. La razón es que el valor de retorno predeterminado de Mage_Adminhtml_Controller_Action::_isAllowed()ha cambiado de truea Mage::getSingleton('admin/session')->isAllowed('admin'). Las extensiones que no anulan este método en sus controladores de administrador porque no usan la ACL, ahora necesitan el privilegio "TODOS" .

La única solución es parchear las extensiones y agregar este método a todos sus controladores de administrador:

protected function _isAllowed()
{
    return true;
}

O si realmente tienen un recurso ACL definido en etc/adminhtml.xml:

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

Cómo determinar el identificador de recurso

Así es como adminhtml.xmlpodría verse un:

Ejemplo de Mage_Setup (acl)

Tome los nombres de nodo a continuación acl/resources/admin/children, omitiendo los siguientes childrennodos.

Cómo crear identificadores de recursos faltantes

Si solo hay una <menu>definición pero no una <acl>definición, también puede definir la suya propia (no tiene que estar dentro del mismo módulo, por lo que no es necesario modificar los archivos de terceros):

Ejemplo de Mage_Setup (menú)

Copiar todo por debajo menude acl/resources/admin/childreny quitar los <action>nodos.


Arreglo automático

Hay una buena herramienta de línea de comandos de SupportDesk.nu en https://gist.github.com/raybogman/eec47237b8ef0d4dd0fd

Maneja la mayoría de las _isAllowed()llamadas perdidas bastante bien, pero dará como resultado un código roto con archivos fuente encriptados u ofuscados, por lo que aún debe verificar los resultados manualmente.

Fabian Schmengler
fuente
Acabo de probar esta solución, y otorgar el permiso "Panel" no hace ninguna diferencia. ¿Es el "privilegio del panel" el mismo que el permiso "Panel" en Role Resources o se encuentra en otro lugar?
Chris
2
Actualicé la respuesta, interpreté mal la configuración admin, en realidad solo devuelve verdadero para los usuarios con todos los privilegios.
Fabian Schmengler
3
No lo haga solo return true;si no hay nada definido para ACL en su config.xmlo adminhtml.xml. En su lugar, agregue los permisos al archivo xml y verifíquelo correctamente. Eche un vistazo al sitio de Alan Storm o aquí para obtener información sobre cómo crear permisos.
kel
Está funcionando bien para el módulo personalizado, pero si hay una sección para la configuración, ¿cómo podemos dar acceso a este bloque?
mjdevloper
1
Controladores para rutas con las que se confunde <use>admin</use>. Suelen extenderse Mage_Adminhtml_Controller_Action.
Fabian Schmengler
2

En mi caso para módulos de terceros, agregar el siguiente código a los controladores adminhtml funcionó:

protected function _isAllowed()

{
     return true;
}
Ankur Jain
fuente
-5

Debería ser:

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

En ese caso, devuelve la configuración de ACL de Magento. Me pregunto si Magento Core Team lo arreglará con otro parche o si esto debería hacerse en la aplicación / código / local como una solución global ...

Piotr Siejczuk
fuente
3
Este no es el comportamiento previsto. Hicieron que los controladores administrativos fueran restrictivos por defecto a propósito. Entonces, en realidad, los proveedores de extensiones se ven obligados a actualizar ahora.
Fabian Schmengler
1
Entonces, sí, si eso funciona para usted, corríjalo app/code/local, pero mostrar extensiones personalizadas sin ACL si y solo si el usuario tiene permisos System > Configurationno es lo que todos desearían.
Fabian Schmengler
¡Su solución es una solución alternativa y no se recomienda! Puede devolver verdadero por defecto (como estaba en el controlador de administración antes de este parche). La mejor solución: configure sus listas de control de acceso correctamente.
Matthias Kleine