Tym razem przerażony problem z pętlą przekierowania logowania do panelu administracyjnego WordPress „Reauth = 1” ugryzł mnie tym razem i w tym poście udostępniam informacje o tym, jak to naprawiłem. Nie jestem w żaden sposób ekspertem od Apache, Linuxa lub WordPressa, ale informacje tutaj mogą pomóc innym, którzy mogą spotkać się z tą samą sytuacją.
Jedna z trzech zmian konfiguracji, które wprowadziłem w panelu sterowania hosta, spowodowała pętlę logowania administratora WordPress.
Zmień 1
Podłączyłem moją domenę do CloudFlare i zainstalowałem wtyczkę CloudFlare WordPress. CDN działał doskonale.
Zmień 2
W Panelu sterowania Plesk podłączyłem się do instalacji WordPress. Plesk pokazał czerwony znak w pobliżu mojej instalacji WordPress, który po kliknięciu poprosił mnie o sprawdzenie bezpieczeństwa mojej instalacji WordPress. Powiedziało:
Zobacz wyniki kontroli bezpieczeństwa dla wybranych instalacji WordPress. Jeśli niektóre dane nie przeszły kontroli bezpieczeństwa, możesz wybrać te dane z listy i wzmocnić ich bezpieczeństwo.
Wybieram klucze bezpieczeństwa z listy i klikam Bezpieczne.
Opis klucza bezpieczeństwa mówi:
WordPress używa kluczy bezpieczeństwa (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY i NONCE_KEY), aby zapewnić lepsze szyfrowanie informacji przechowywanych w plikach cookie użytkownika…. Jeśli kontrola bezpieczeństwa się nie powiedzie i zdecydujesz się zabezpieczyć instalację WordPress, dobre klucze bezpieczeństwa zostaną wygenerowane i dodane do instalacji WordPress.
Zmień 3
Rozpoczął nginx od zarządzania usługami w Plesku.
Pętla logowania
Następnym razem, gdy próbowałem zalogować się do WordPress, po prostu przekierowałem na stronę „Reauth = 1”. Jeśli celowo wpisałem nieprawidłowe hasło, oznaczało to, że hasło jest nieprawidłowe. Tak więc uwierzytelnianie działało dobrze, ale z jakiegoś powodu przekierowano na adres URL Reauth, gdy użyto prawidłowych poświadczeń. Oto lista rzeczy, które próbowałem i żadna z nich (poza tym, że może być # 15 poniżej) nie pomogła.
- Całkowicie wyczyściłem pamięć podręczną przeglądarki i wypróbowałem różne przeglądarki.
- Zatrzymano nginx, jak czytano o problemie z buforowaniem (nginx.conf)
- Wyłączono wtyczkę CloudFlare przez Plesk, ponieważ złamała funkcje WP Admin dla niektórych użytkowników
- Wyłączono WSZYSTKIE wtyczki i zrestartowano serwer
- Zoptymalizowano i naprawiono bazę danych przez PhpMyAdmin
- Zweryfikowany adres URL witryny w tabeli wp_options. To było poprawne
- Zweryfikowane uprawnienia do plików wp-config, wp-admin i wp-obejmuje katalogi
- Dodano WP_HOME i WP_SITEURL w wp-config.php
- Wygenerowano nowe kody SALT lub Secret i dodano do wp-config.php
- Aktywowano motyw Twenty Sixteen
- Opublikowane na forach WordPress i absolutnie bez odpowiedzi
- Przywróciłem moją witrynę z najnowszej kopii zapasowej VaultPress
- Włączono tryb programowania w CloudFlare
- Ustaw CloudFlare PageRule, aby ominąć buforowanie stron administracyjnych (WP- *)
- Odłączyłem moją witrynę od CloudFlare
Oprócz powyższych, zrobiłem wiele innych rzeczy, z których niektóre mogą być trywialne. Poważnie zastanawiałem się nad tymi opcjami:
- Poszukaj profesjonalnej pomocy CloudTech (za pośrednictwem panelu administracyjnego MT) za 79 USD, ale naprawa nie jest gwarantowana.
- Zresetuj Plesk DV do wartości domyślnych. Ale przywrócenie wszystkiego zajęłoby dużo czasu.
- Żądanie przywrócenia awaryjnego, ponownie za 79 USD. Przywracana jest tylko zawartość witryny, co już zrobiłem z VaultPress.
- Odrzuć serwer i przejdź do zarządzanego Premium WordPress Hosting tego samego dostawcy. W ten sposób wykorzystuje domyślne ustawienia serwera.
- Jeśli wsparcie MT nie pomogło, przejdź do DreamHost
W mojej głowie krążyło wiele pomysłów i jeden cały dzień został zmarnowany. Kilka godzin po odłączeniu mojej witryny od CloudFlare teraz WordPress wyświetla inny komunikat o błędzie. Mówi teraz „Pliki cookie są zablokowane”, chociaż wszystkie moje przeglądarki internetowe są ustawione na akceptowanie plików cookie.
Naprawiono to Atlast!
Krok 1:
W wp-config usunąłem te linie, które zawierały tajne klucze:
Definiuj („AUTH_KEY” Definiuj („SECURE_AUTH_KEY” Definiuj („LOGGED_IN_KEY” Definiuj („NONCE_KEY” Definiuj)
Krok 2:
Zapisałem plik z kodowaniem UTF-8 (pokazywany był jako ANSI). Chociaż to wcale NIE może powodować problemu… ale właśnie go wypróbowałem.
Wreszcie udało mi się zalogować do panelu administracyjnego WordPress. Następnie wygenerowałem nowe klucze bezpieczeństwa, wylogowałem się z WordPress i zalogowałem ponownie. Zadziałało!
Co spowodowało problem?
Podczas gdy większość postów w Internecie wskazywała na najnowszą wtyczkę CloudFlare, w moim przypadku tak nie było. Domyślam się, że Plesk's Security Check (w zmianie nr 2 powyżej) go złamał, ponieważ dopiero po usunięciu tajnych kluczy z wp-config.php pozwolono mi się zalogować. Oczywiście wygenerowałem nowe klucze bezpieczeństwa, zaktualizowałem wp-config.php. Następnie ponownie podłączyłem moją witrynę do CloudFlare i włączyłem ich wtyczkę.
Na szczęście problem nie pojawił się do tej pory!
Morał tej historii (powiedziałem sobie): Nie baw się ustawieniami w Plesku, jeśli nie wiesz, co robisz. I dokonuj jednej zmiany na raz, i to tylko wtedy, gdy jest to absolutnie konieczne, abyś wiedział, które ustawienie powoduje problem. Linux / Apache nie jest podobny do Windows… są bardziej złożone, przynajmniej dla mnie. Jeśli ten post pomógł Ci lub masz dodatkowe dane do rozwiązania tego problemu, podziel się swoimi przemyśleniami w sekcji Komentarze poniżej.
