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);
Odpowiedzi:
Miałem również ten sam problem i był z tym związany
mod_rewrite. Włączyłemmod_rewritenastępujące polecenie i problem został rozwiązany.źródło
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';źródło
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.
źródło
Nie oznacza to, że rozwiąże to problem, ale jeśli musisz się zalogować, zawsze możesz uzyskać jednorazowy link do logowania z Drush:
źródło