Erro - chave de formulário inválida

Encontro um problema com o magento 1.9.2.3, uma mensagem de erro aparece quando eu me conecto com meu formulário de administrador personalizado.

Criei um módulo e dupliquei a página de cliente / conta / login para minha função de usuário.

<?xml version="1.0"?>
<config>
    <modules>
        <Custom_Page>
            <active>true</active>
            <codePool>local</codePool>
        </Custom_Page>
    </modules>
</config>

meu config.xml:

<?xml version="1.0"?>
<config>
    <global>
        <page>
            <layouts>
                <Custom_Page>
                    <label>User Login</label>
                    <template>page/user_login.phtml</template>
                </Custom_Page>
            </layouts>
        </page>
    </global>
</config>

Não há problema com a versão antiga do magento.

Mas com 1.9.2.3: A chave de formulário inválida. Atualize a página exibida.

NOTA: Se eu substituir o antigo Observer.php, ele estará pronto:

www \ app \ code \ core \ Mage \ Admin \ Model \ Observer.php

Mas acho que não é sério substituir o novo Observer.php pelo antigo.

EDIT: Meu user_login.phtml contém uma entrada form_key.

<form action="/admin" method="post" id="login-form">
    <input type="hidden" name="form_key" value="<?php echo Mage::getSingleton('core/session')->getFormKey() ?>"/>

Obrigado pela ajuda.

Eu tive o mesmo problema e poderia corrigi-lo, definindo o

web / cookie / cookie_domain

e

web / cookie / cookie_path

valores na tabela core_config_data.

Não se esqueça de limpar todos os dados da sessão e dos cookies no seu navegador e da sessão Magento e armazenar em cache os arquivos / dados posteriormente.

Usei essas consultas e consegui entrar novamente

DELETE FROM core_config_data WHERE path='web/cookie/cookie_domain'; DELETE FROM core_config_data WHERE path='web/cookie/cookie_path';

e verifique se o usuário do servidor da web tem o direito de gravar no armazenamento da sessão. verificação de session_save_pathconfiguração se você salvar a sessão em arquivos. Se parece com isso

<session_save><![CDATA[files]]></session_save> <session_save_path><![CDATA[/tmp/session]]></session_save_path>

Verifique suas configurações para https. Se você usar https para o seu magento, mas tentar abrir um site com http, você terá um problema.

Eu recebi esse erro após atualizar para o php7.0 . executando o magento enterprise 1.9 . Então eu tentei todas as sugestões por aí. Aqui está como eu consegui funcionar:

1. Adicionei o relatório de erros no meu index.php e corrigi todos os erros relatados.

2. Na tabela MySQL core_config_data, limpei os valores para web/cookie_path web/cookie_httponly. Verifique se você tem o web/cookie_domain valor certo com seu domínio (muito importante).

3. Limpe o cache e os cookies do navegador .

As versões mais recentes do Magento exigem que os formulários tenham <input type="hidden" name="form_key" value="<?php echo Mage::getSingleton('core/session')->getFormKey() ?>" />que impedir ataques CSRF (Cross-Site Request Forgery).

Eu tive o mesmo erro com o Magento 1.9.2.3 depois de copiar o site no servidor da web local no MAMP 3.

Então, problema resolvido quando eu mudei na tabela core_config_datado web/cookie/cookie_domainque mysite.lanem vez do mysite.lan:8888.

No meu caso, isso estava funcionando no Linux, mas no meu ambiente local do Windows usando o virtualbox / Docker e o Windows 10, esse erro foi causado pelas permissões estranhas que o vb / docker / windows dá a / var / sessions /. Apenas no meu ambiente de desenvolvimento local, mudei o caminho de uma unidade de janelas mapeada para um caminho "real" na VM linux

Eu adicionei isso para o arquivo de configuração app/etc/local.xml, em seguida, excluído todos os arquivos var/cachee var/sessione poderia entrar em OK.

<session_save><![CDATA[files]]></session_save>
<session_save_path><![CDATA[/tmp]]></session_save_path>

No meu caso, criei o erro com estas etapas: Eu havia movido uma cópia magento (dev) no próprio magento : magento / magento-copy Antes, eles estavam próximos um do outro no servidor. Todo mundo com sua própria cota. Então, movendo um qutoa para o outro -> problemas ocorreram. Porque não consegui visualizar a cópia magento com FTP, mudei o proprietário dos arquivos pelo editor de arquivos. Por qualquer motivo, isso criou o erro.

Verifique se você pode fazer login em https: // yourwebsite / admin em vez de http e verifique core_config_data web / secure / use_in_adminhtml

Eu tenho um problema semelhante e o login funciona apenas no Secure

Costumo ter esse problema quando estou trabalhando em vários sites de desenvolvimento e sites ativos, e há alguma confusão de cookies. Anteriormente, eu o corrigi com consultas MySQL e exclusão de arquivos, mas encontrei uma maneira mais clara de resolver o problema.

A ferramenta magerun fornece uma maneira de verificar problemas no caminho do cookie e corrigi-los. O magerun não faz parte do Magento, portanto você precisará instalá-lo. É descrito como um canivete suíço para magento, para que você possa achar útil para outras coisas.

Para fazer o download:

wget https://files.magerun.net/n98-magerun.phar

Então

chmod +x n98-magerun.phar

Em seguida, verifique se há problemas no caminho do cookie ...

./n98-magerun.phar config:get web/cookie/*

Irá imprimir uma tabela. Veja o valor para web/cookie/cookie_domain. Quando estou com esse problema, ele não corresponde ao nome do host apropriado para o site (por exemplo, eu recebo em dev.example.comvez de www.example.com).

Para corrigi-lo, você precisa redefinir o caminho e liberar o cache, o que o magerun pode ajudar ...

./n98-magerun.phar config:set web/cookie/cookie_domain ""
./n98-magerun.phar cache:flush

Você deve conseguir fazer login novamente.

Meu problema foi o php versão 7.2.

alterar minha versão php para 5.6 em .htaccess

Aplicativo AddHandler / x-httpd-php56 .php suPHP_ConfigPath / opt / php56 / lib

Outra maneira que esse erro pode ocorrer em módulos de administração caseiros é quando o frontNameseu routes.xmlnão corresponde ao <add action"someFrontName/someAction" />seu menu.xml. Isso faz com que a chave que você vê no link ao tentar abrir o módulo seja diferente do esperado.

Em relação à resposta aceita ( https://magento.stackexchange.com/a/102678/6078 ), as entradas corretas são

web / cookie / cookie_domain = seu URL base, como:

https://website.com/ (without any store code)

e

web / cookie / cookie_path

normalmente apenas, /mas /[storecode]|também pode ser por loja

Para o desenvolvimento local, geralmente funciona para excluir cookie_domainou deixá-lo vazio, mas parece que o Microsoft Edge 80 tem problemas com isso.