Det frygtede WordPress "Reauth = 1" Admin-panelets logon-omdirigeringsløkeproblem bet mig denne gang, og jeg deler oplysningerne om, hvordan jeg fikste det, i dette indlæg. Jeg er på ingen måde ekspert i Apache, Linux eller WordPress-ting, men informationen her kan hjælpe andre, der tilfældigvis står over for den samme situation.
En af de tre konfigurationsændringer, jeg foretog på hosting-kontrolpanelet, forårsagede WordPress Admin-logon loop.
Skift 1
Jeg knyttet mit domæne til CloudFlare og installerede CloudFlare WordPress Plugin. CDN fungerede helt fint.
Skift 2
I Plesk Kontrolpanel sluttede jeg mig til min WordPress-installation. Plesk viste et rødt skilt i nærheden af min WordPress-installation, som, når det blev klikket, bad mig om at kontrollere sikkerheden for min WordPress-installation. Den sagde:
Se resultaterne af sikkerhedskontrollen for de valgte WordPress-installationer. Hvis nogle data ikke bestod sikkerhedskontrollen, kan du vælge disse data på listen og hærde deres sikkerhed.
Jeg vælger Sikkerhedsnøgler på listen og klikkede på Sikker.
Beskrivelse af sikkerhedsnøgle siger:
WordPress bruger sikkerhedstaster (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY og NONCE_KEY) for at sikre bedre kryptering af oplysninger, der er gemt i brugerens cookies…. Hvis sikkerhedskontrollen mislykkedes, og du vælger at sikre WordPress-installationen, genereres og tilføjes gode sikkerhedstaster til din WordPress-installation.
Skift 3
Startede nginx fra Services Management i Plesk.
Logon-loop
Næste gang jeg prøvede at logge på WordPress, blev det ganske enkelt omdirigeret til siden "Reauth = 1". Hvis jeg bevidst indtastede en forkert adgangskode, sagde den, at adgangskoden var forkert. Så autentificeringsmaterialet fungerede fint, men af en eller anden grund blev det omdirigeret til Reauth URL, når korrekte legitimationsoplysninger blev brugt. Her er en liste over ting, jeg prøvede, og ingen af dem (undtagen kan være nr. 15 nedenfor) hjalp.
- Ryddet cache for webbrowser og prøvet forskellige browsere.
- Stoppet nginx, som læst om et cache-problem (nginx.conf)
- Deaktiveret CloudFlare-plugin via Plesk, da det ødelagte WP Admin-funktioner for nogle brugere
- Deaktiverede ALLE plugins og genstartede serveren
- Optimeret og repareret databasen via PhpMyAdmin
- Verificeret webstedswebadresse i wp_options-tabel. Det var korrekt
- Bekræftede tilladelser til wp-config-filer, wp-admin og wp-inkluderer mapper
- Tilføjet WP_HOME og WP_SITEURL i wp-config.php
- Genereret nye SALT- eller Secret-nøglekoder og føjet til wp-config.php
- Aktiverede Twenty Sixteen-temaet
- Indsendt i WordPress-fora, og absolut intet svar
- Gendannet mit websted fra den seneste VaultPress-sikkerhedskopi
- Aktiveret udviklingsfunktion i CloudFlare
- Indstil CloudFlare PageRule til at omgå cache til administrator sider (WP- *)
- Frakoblet mit websted fra CloudFlare
Der var mange andre ting, jeg gjorde udover ovenstående, hvoraf nogle af dem kan være trivielle. Jeg overvejede seriøst disse muligheder:
- Søg CloudTechs professionel hjælp (via MT Admin Panel) for $ 79, men en rettelse er ikke garanteret.
- Nulstil Plesk DV til standardindstillinger. Men at genoprette alt ville tage meget tid.
- Anmodning om nødgendannelse igen for $ 79. Kun webstedsindhold gendannes, hvilket jeg allerede har gjort fra VaultPress.
- Kassér serveren og flyt til administreret Premium WordPress Hosting af den samme udbyder. Derved bruger den standard serverindstillingerne.
- Hvis MT's support ikke hjalp, skal du flytte til DreamHost
Masser af ideer løb i mit sind, og en hel dag blev spildt. Få timer efter at have fjernet mit websted fra CloudFlare, kaster WordPress nu en anden fejlmeddelelse. Den siger nu "Cookies er blokeret", selvom alle mine webbrowsere er indstillet til at acceptere cookies.
Fast det Atlast!
Trin 1:
I wp-config fjernede jeg disse linjer, der indeholdt de hemmelige nøgler:
define ('AUTH_KEY' define ('SECURE_AUTH_KEY' define ('LOGGED_IN_KEY' definere) Trin 2:
Gemt filen med UTF-8-kodning (den blev vist som ANSI). Selvom dette muligvis IKKE forårsager problemet ... men jeg har lige prøvet det.
Endelig kunne jeg logge ind på WordPress Admin Panel. Derefter genererede jeg nye sikkerhedstaster, logget ud af WordPress og logget ind igen. Det virkede!
Hvad forårsagede problemet i første omgang?
Mens de fleste indlæg på internettet pegede på det nylige CloudFlare-plugin, var det ikke i min sag. Jeg gætter på, at Plesks sikkerhedskontrol (i ændring nr. 2 ovenfor) brød den, da jeg først fik lov til at logge ind efter at have fjernet de hemmelige nøgler fra wp-config.php. Selvfølgelig genererede jeg derefter nye sikkerhedstaster, opdateret wp-config.php. Derefter tilknyttede jeg mit websted igen til CloudFlare og aktiverede deres plugin.
Heldigvis syntes problemet ikke indtil videre!
Moral for historien (sagde jeg til mig selv): Spil ikke med indstillingerne i Plesk, hvis du ikke ved, hvad du laver. Og foretage en ændring ad gangen, og det også kun, hvis det er absolut nødvendigt, så du ved, hvilken indstilling der forårsager et problem. Linux / Apache er ikke som Windows… de er mere komplekse, i det mindste for mig. Hvis dette indlæg hjalp dig, eller du har yderligere input til at løse dette problem, skal du dele dine tanker i afsnittet Kommentarer nedenfor.
