84

After installing the SUPEE-6285 patch on our Magento 1.7.0.2 store the system is showing an "Access Denied" error when attempting to access all custom modules for users who have selective permissions (not all permissions). Screenshot below.

enter image description here

The user permissions are properly set in Role Resources and we have re-applied the permission settings to ensure these are set.

The problem has been reproduced across multiple custom extensions so it isn't just a single extension that isn't working.

I have logged out/in, cleared the cache and confirmed that the compiler is disabled.

Can anyone suggest how to troubleshoot this?

129

As written here:

If you use restricted admin accounts, some menus of third party extensions might not work anymore for them. The reason is that the default return value of Mage_Adminhtml_Controller_Action::_isAllowed() has been changed from true to Mage::getSingleton('admin/session')->isAllowed('admin'). Extensions that do not override this method in their admin controllers because they don't use the ACL, now need the "ALL" privilege.

The only solution is to patch the extensions and add this method to all their admin controllers:

protected function _isAllowed()
{
    return true;
}

Or if they actually have an ACL resource defined in etc/adminhtml.xml:

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

How to determine the resource identifier

This is how an adminhtml.xml might look like:

Mage_Setup example (acl)

Take the node names below acl/resources/admin/children, skipping following children nodes.

How to create missing resource identifiers

If there is only a <menu> definition but no <acl> definition, you can also define your own (it does not have to be within the same module, so no 3rd party files have to be modified)::

Mage_Setup example (menu)

Copy everything below menu to acl/resources/admin/children and remove the <action> nodes.


Automatic fix

There is a good command line tool by SupportDesk.nu at https://gist.github.com/raybogman/eec47237b8ef0d4dd0fd

It handles most missing _isAllowed() calls quite well but will result in broken code with obfuscated or encrypted source files, so you still should check the results manually.

  • Just tested this solution, and giving the "Dashboard" permission makes no difference. Is the "Dashboard privilege" the same as the "Dashboard" permission under Role Resources or is this somewhere else? – Chris Jul 8 '15 at 13:26
  • 2
    Updated the answer, I misinterpreted the configuration for admin, it actually only returns true for users with all privilieges. – Fabian Schmengler Jul 8 '15 at 14:06
  • 3
    Please do not just do return true; if there is nothing defined for ACL in your config.xml or adminhtml.xml. Instead add the permissions to the xml file and check it properly. Take a look Alan Storm's site or here for info on creating permissions. – kel Jul 9 '15 at 16:53
  • It is working fine for custom module but if there is section for configuration setting, how can we gives access for this block? – mjdevloper Jul 13 '15 at 8:15
  • 1
    Controllers for routes that are configued with <use>admin</use>. They usually extend Mage_Adminhtml_Controller_Action. – Fabian Schmengler Oct 9 '15 at 10:18
2

In my case for third party modules, adding below code to the adminhtml controllers worked:

protected function _isAllowed()

{
     return true;
}
-5

It should be:

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

In that case it returns ACL Settings from Magento. I am just wondering if Magento Core Team will fix it with another Patch or this should be done in app/code/local as a global Fix...

  • 3
    This is not the intended behavior. They made the admin controllers restrictive by default on purpose. So actually the extension vendors are forced to update now. – Fabian Schmengler Jul 8 '15 at 14:31
  • 1
    So, yes, if that works for you, fix it in app/code/local, but showing custom extensions without ACL if and only if the user has permissions for System > Configuration is not what everbody would want. – Fabian Schmengler Jul 8 '15 at 14:34
  • Your solution is a workaround and is not recommended! You can return true by default (as it was in admin controller before this patch). The better solution: Configure your Access Control Lists correctly. – Matthias Kleine Jul 13 '15 at 15:35

protected by Community Feb 17 '16 at 6:19

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.