Não consigo fazer login após a migração

9

Eu pesquisei o que parecem centenas de soluções e as implementei. Também procurei neste site para encontrar a mesma pergunta, mas não consegui localizá-lo.

Eu tenho um site de desenvolvimento e um site de produção. Para migrar entre os dois, eu uso o github push and pull. Isso não foi um problema no passado, no entanto, eu encontrei esse problema várias vezes. Após uma migração de arquivos, o Drupal não me permite mais fazer login. Tento minhas credenciais de login e recebo imediatamente uma página Acesso negado.

Os cookies do meu site estão lendo e escrevendo sem problemas. Localizei o ID do cookie e achei sua entrada no banco de dados. Portanto, os cookies parecem estar funcionando bem e as entradas do banco de dados estão funcionando um pouco.

O problema que vejo é que os registros da sessão do banco de dados não estão salvando nenhum ID do usuário. Quando altero manualmente o ID do usuário no registro db para 1, para o meu IP, e atualizo o site, estou logado. Alguma idéia?

/programming/2846935/cannot-login-to-drupal-in-chrome-or-firefox-but-safari-works sugere que eu atualize $ cookie_domain no arquivo settings.php. Eu tentei todas as configurações e não ajudou.
http://www.go2linux.org/cannot-login-into-drupal-table-corrupted também sugerem que eu repare a tabela de sessões. Eu fiz isso, limpei as sessões do banco de dados e limpei meus cookies. Não funcionou.
http://www.madebymorgan.com/blog/2010/07/15/cant-login-after-drupal-617-upgrade sugere que eu atualize os valores no meu arquivo settings.php: $ cookie_domain e $ base_url. Eu tentei todas as combinações e não tive sucesso.
Eu li o install.txt que diz para executar os seguintes comandos para os níveis de permissão e de propriedade apropriadas: chmod o+w sites/default/settings.php, chmod o+w sites/default, chmod o+w sites/default/files, chmod a-w sites/default/settings.php, chmod a-w sites/default. Não deu certo.
O patch em http://drupal.org/node/56357#comment-236726 adiciona algum código ao seu arquivo de sessões. Eu fiz isso e não funcionou.
Em http://drupal.org/node/56357#comment-391535 , o markus_petrux teve uma boa sugestão ao definir o PHPSESSID com um novo nome, além de definir manualmente o domínio e o caminho do cookie. Não deu certo.
http://old.nabble.com/Re%3A-Can%27t-login-p22258960.html sugere adicionar register_shutdown_function('session_write_close');no final do settings.php funciona, o que também não funcionou para mim.
http://drupal.org/node/6696#comment-204863 nos diz para adicionar algumas configurações de ini no settings.php, limpar o cache, limpar cookies, limpar a privacidade, reiniciar o Firefox e adicionar ao settings.php as seguintes linhas:

ini_set('session.cookie_domain', 'exampleorg');
ini_set('session.cookie_domain','www.example.org');
ini_set('session.auto_start', 0);

— Consultor de comércio eletrônico
fonte

Acabei de fazer uma pequena descoberta aqui. Meu site continua alternando entre HTTPS e HTTP durante o login. Então, eu estou querendo saber se isso está jogando fora da sessão.

— Consultor de comércio eletrônico

OMG, ENCONTREI MEU PROBLEMA. Eu configurei meu host virtual errado para o meu SSL. Meu SSL estava apontando para o meu site de desenvolvimento e não para o meu site ao vivo. Portanto, o fato de que ele estava me redirecionando após o login para o ssl significava que eu estava mudando totalmente os sites. que era horrível ... me levou todo o dia ..

— Ecommerce Consultant

6

Eu também tive o mesmo problema, e estava relacionado a mod_rewrite. Eu ativei o mod_rewritecom o seguinte comando e o problema foi corrigido.

sudo a2enmod rewrite

— Елин Й.
fonte

Às vezes, é a mais simples das soluções. Obrigado!

— mcriecken

3

Para sua informação, o arquivo sites \ default \ settings.php deve conter um cookie com o mesmo nome do caminho que você está usando, por isso, se o servidor da Web anterior tivesse um domínio www.boldlygowherenomanhasgonebefore.com e você mudou o drupal para o host local, o cookie O domínio deve refletir essa alteração:

FOI: $cookie_domain = '.boldlygowherenomanhasgonebefore.com';
MUDAR PARA: $cookie_domain = '.localhost';

— Brandon Ferrara
fonte

Você ganhou :) Este é exatamente o que eu fiz

— qasimzee

1

Obviamente, não é a sua solução, mas para qualquer pessoa que venha aqui, tive um problema semelhante (não foi possível fazer o login), mas o meu era um problema de URLs limpo, resolvido da seguinte maneira:

Havia algo acontecendo com URLs limpas, elas estavam semi-funcionando, e é por isso que eu as descartei como o problema, mas era.

Eventualmente, tive que editar a tabela de variáveis no banco de dados (alterando LONGBLOB para LONGTEXT para que eu pudesse), desliguei o sinalizador de URLs limpos (configure "1" para "0"), limpe os caches para remover a versão em cache das variáveis.

E então as coisas deram certo.

— Adaddinsane
fonte

0

Não que isso resolva a raiz do problema, mas se você precisar fazer login, poderá sempre obter um link de login único no Drush:

drush user-login theusername

— Hans Rossel
fonte