Nie mogę się zalogować po migracji

9

Przeszukałem setki rozwiązań i wdrożyłem je wszystkie. Przeszukałem również tę stronę, aby znaleźć to samo pytanie, ale nie mogłem jej znaleźć.

Mam witrynę programistyczną i produkcyjną. Do migracji między nimi używam github push i pull. W przeszłości nie było to problemem, jednak wielokrotnie napotykałem ten problem. Po migracji pliku Drupal nie pozwala mi się zalogować. Próbuję uzyskać dane logowania i natychmiast otrzymuję stronę Odmowa dostępu.

Pliki cookie z mojej witryny odczytują i zapisują bez problemu. Znalazłem identyfikator pliku cookie i znalazłem jego wpis w bazie danych. Wygląda na to, że pliki cookie działają poprawnie, a wpisy w bazie danych działają całkiem dobrze.

Problem, który widzę, polega na tym, że rekordy sesji bazy danych nie zapisują żadnych identyfikatorów użytkowników. Kiedy ręcznie zmieniam identyfikator użytkownika w rekordzie db na 1, dla mojego adresu IP, a następnie odświeżam witrynę, jestem zalogowany. Jakieś pomysły?

/programming/2846935/cannot-login-to-drupal-in-chrome-or-firefox-but-safari-works sugeruje aktualizację $ cookie_domain w pliku settings.php. Próbowałem każdej konfiguracji i to nie pomogło.
http://www.go2linux.org/cannot-login-into-drupal-table-corrupt sugeruje również, że naprawię tabelę sesji. Zrobiłem to, wyczyściłem sesje z bazy danych i wyczyściłem pliki cookie. To nie działało.
http://www.madebymorgan.com/blog/2010/07/15/cant-login-after-drupal-617-upgrade sugeruje, że zaktualizuję wartości w moim pliku settings.php: $ cookie_domain i $ base_url. Próbowałem każdej kombinacji i nie powiodło się.
Czytałem install.txt który mówi, aby uruchomić następujące polecenia do właściwych poziomów uprawnień i własności: 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. Nie działało.
Łatka w http://drupal.org/node/56357#comment-236726 dodaje trochę kodu do pliku sesji. Zrobiłem to i to nie działało.
Na http://drupal.org/node/56357#comment-391535 markus_petrux miał dobrą sugestię, definiując PHPSESSID nową nazwą, a także ręcznie ustawiając domenę i ścieżkę plików cookie. Nie działało.
http://old.nabble.com/Re%3A-Can%27t-login-p22258960.html sugeruje dodanie register_shutdown_function('session_write_close');na końcu ustawień settings.php, które również nie działały dla mnie.
http://drupal.org/node/6696#comment-204863 mówi nam, abyśmy dodali niektóre ustawienia ini do ustawień.php, wyczyścili pamięć podręczną, wyczyścili pliki cookie, wyczyścili prywatność, uruchom ponownie Firefox i dodali do settings.php następujące linie:

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

— Konsultant ds. E-commerce
źródło

Właśnie dokonałem małego odkrycia tutaj. Moja witryna ciągle przełącza się między HTTPS a HTTP podczas logowania. Zastanawiam się więc, czy to zepsuło sesję.

— Konsultant ds. E

OMG ZNALAZŁEM SWÓJ PROBLEM. Źle skonfigurowałem mojego wirtualnego hosta dla mojego SSL. Moje SSL wskazywało na moją witrynę programistyczną, a nie na aktywną. Więc fakt, że przekierowywał mnie przy logowaniu do ssl, oznaczał, że całkowicie zmieniałem strony internetowe. to było przerażające ... zajęło mi cały dzień ..

— Konsultant ds. e

6

Miałem również ten sam problem i był z tym związany mod_rewrite. Włączyłem mod_rewritenastępujące polecenie i problem został rozwiązany.

sudo a2enmod rewrite

— Елин Й.
źródło

Czasami jest to najprostsze rozwiązanie. Dziękuję Ci!

— mcriecken

3

Do Twojej wiadomości, plik twoich stron \ default \ settings.php powinien zawierać plik cookie o tej samej nazwie co ścieżka, której używasz, więc jeśli twój poprzedni serwer WWW miał domenę www.boldlygowherenomanhasgonebefore.com i przeniosłeś swojego drupala na localhost, ciasteczko domena musi odzwierciedlać tę zmianę:

BYŁO: $cookie_domain = '.boldlygowherenomanhasgonebefore.com';
ZMIANA NA: $cookie_domain = '.localhost';

— Brandon Ferrara
źródło

— Wygrałeś

1

Oczywiście nie twoje rozwiązanie, ale dla każdego, kto tu przyjeżdża, miałem podobny problem (nie mogłem się zalogować), ale mój problem dotyczący czystych adresów URL został rozwiązany w następujący sposób:

Coś się działo z czystymi adresami URL, działały one częściowo, dlatego odrzuciłem je jako problem, ale tak było.

W końcu musiałem edytować tabelę zmiennych w DB (zmieniając LONGBLOB na LONGTEXT, więc mogłem), wyłączyłem flagę czystych adresów URL (ustawiłem „1” na „0”), wyczyściłem pamięć podręczną, aby usunąć buforowaną wersję zmiennych.

A potem wszystko poszło dobrze.

— Adaddinsane
źródło

0

Nie oznacza to, że rozwiąże to problem, ale jeśli musisz się zalogować, zawsze możesz uzyskać jednorazowy link do logowania z Drush:

drush user-login theusername

— Hans Rossel
źródło