Erros de acesso negado após a instalação do SUPEE-6285

Após instalar o patch SUPEE-6285 em nossa loja Magento 1.7.0.2, o sistema mostra um erro " Acesso negado " ao tentar acessar todos os módulos personalizados para usuários que possuem permissões seletivas (nem todas). Captura de tela abaixo.

As permissões do usuário estão definidas corretamente em Recursos da função e reaplicamos as configurações de permissão para garantir que elas sejam definidas.

O problema foi reproduzido em várias extensões personalizadas, portanto, não é apenas uma única extensão que não está funcionando.

Efetuei logoff / logoff, limpei o cache e confirmei que o compilador está desabilitado.

Alguém pode sugerir como solucionar isso?

Como está escrito aqui :

Se você usar contas de administrador restritas, alguns menus de extensões de terceiros poderão não funcionar mais para elas. O motivo é que o valor de retorno padrão de Mage_Adminhtml_Controller_Action::_isAllowed()foi alterado de truepara Mage::getSingleton('admin/session')->isAllowed('admin'). Extensões que não substituem esse método em seus controladores administrativos porque não usam a ACL, agora precisam do privilégio "ALL" .

A única solução é corrigir as extensões e adicionar esse método a todos os seus controladores administrativos:

protected function _isAllowed()
{
    return true;
}

Ou se eles realmente tiverem um recurso ACL definido em etc/adminhtml.xml:

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

Como determinar o identificador de recurso

É assim que um adminhtml.xmlpode parecer:

Pegue os nomes dos nós abaixo acl/resources/admin/children, pulando os seguintes children.

Como criar identificadores de recursos ausentes

Se houver apenas uma <menu>definição, mas nenhuma <acl>definição, você também poderá definir sua própria (ela não precisa estar no mesmo módulo, portanto, nenhum arquivo de terceiros precisa ser modificado) ::

Copie tudo abaixo menuao acl/resources/admin/childrene remover os <action>nós.

Correção automática

Há uma boa ferramenta de linha de comando do SupportDesk.nu em https://gist.github.com/raybogman/eec47237b8ef0d4dd0fd

Ele lida com a maioria das _isAllowed()chamadas perdidas muito bem, mas resulta em código quebrado com arquivos de origem ofuscados ou criptografados, portanto, você ainda deve verificar os resultados manualmente.

No meu caso para módulos de terceiros, a adição do código abaixo aos adminhtml controllers funcionou:

protected function _isAllowed()

{
     return true;
}

Deveria ser:

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

Nesse caso, ele retorna as configurações de ACL do Magento. Eu estou apenas querendo saber se o Magento Core Team irá corrigi-lo com outro patch ou isso deve ser feito em app / code / local como uma correção global ...