Det fryktede WordPress "Reauth = 1" Problemet med pålogging av administratorpanel pålogging omdirigerte meg litt denne gangen, og jeg deler informasjonen om hvordan jeg fikset det, i dette innlegget. Jeg er ikke på noen måte ekspert på ting fra Apache, Linux eller WordPress, men informasjonen her kan hjelpe andre som tilfeldigvis møter den samme situasjonen.
En av de tre konfigurasjonsendringene jeg gjorde på kontrollpanelet som vert, forårsaket WordPress Admin påloggingssløyfe.
Endre 1
Jeg koblet domenet mitt til CloudFlare og installerte CloudFlare WordPress Plugin. CDN fungerte helt greit.
Endre 2
I Plesk Kontrollpanel koblet jeg til WordPress-installasjonen. Plesk viste et rødt skilt i nærheten av WordPress-installasjonen min, som da jeg klikket, ba meg sjekke sikkerheten til WordPress-installasjonen min. Det sto:
Se resultatene av sikkerhetskontrollen for de valgte WordPress-installasjonene. Hvis noen data ikke passerte sikkerhetskontrollen, kan du velge disse dataene i listen og herde sikkerheten.
Jeg velger sikkerhetstaster fra listen og klikket på Secure.
Sikkerhetsnøkkelbeskrivelse sier:
WordPress bruker sikkerhetsnøkler (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY og NONCE_KEY) for å sikre bedre kryptering av informasjon som er lagret i brukerens informasjonskapsler…. Hvis sikkerhetskontrollen mislyktes, og du velger å sikre WordPress-installasjonen, vil gode sikkerhetsnøkler bli generert og lagt til for din WordPress-installasjon.
Endre 3
Startet nginx fra Services Management i Plesk.
Påloggingssløyfe
Neste gang jeg prøvde å logge meg på WordPress, ble det ganske enkelt omdirigert til siden "Reauth = 1". Hvis jeg bevisst skrev inn et galt passord, sa det at passordet var feil. Så, autentiseringsstoffene fungerte bra, men av en eller annen grunn ble det omdirigert til Reauth URL når riktig legitimasjon ble brukt. Her er en liste over ting jeg prøvde, og ingen av dem (unntatt, kan være # 15 nedenfor) hjalp.
- Tømte nettleserbufferen fullstendig og prøvde forskjellige nettlesere.
- Stoppet nginx, som lest om et cache-problem (nginx.conf)
- Deaktivert CloudFlare-plugin via Plesk, da det brøt WP Admin-funksjoner for noen brukere
- Deaktivert ALLE plugins og startet serveren på nytt
- Optimaliserte og reparerte databasen via PhpMyAdmin
- Bekreftet nettadresse i wp_options-tabellen. Det var riktig
- Bekreftede tillatelser for wp-config-filer, wp-admin og wp-inkluderer kataloger
- Lagt til WP_HOME og WP_SITEURL i wp-config.php
- Genererte nye SALT- eller Secret-nøkkelkoder og lagt til wp-config.php
- Aktiverte Twenty Sixteen-temaet
- Skrevet i WordPress-fora, og absolutt ingen respons
- Gjenopprettet nettstedet mitt fra den nyeste VaultPress-sikkerhetskopien
- Aktivert utviklingsmodus i CloudFlare
- Still CloudFlare PageRule til å omgå cache for administrasjonssider (WP- *)
- Frakoblet nettstedet mitt fra CloudFlare
Det var mange andre ting jeg gjorde i tillegg til ovenstående, hvorav noen av dem kan være trivielle. Jeg vurderte seriøst disse alternativene:
- Søk CloudTechs profesjonelle hjelp (via MT Admin Panel) for $ 79, men en løsning er ikke garantert.
- Tilbakestill Plesk DV til standardinnstillinger. Men å gjenopprette alt vil ta mye tid.
- Nødgjenopprettingsforespørsel, igjen for $ 79. Bare nettstedinnhold er gjenopprettet, noe jeg allerede har gjort fra VaultPress.
- Kast serveren og gå til administrert Premium WordPress Hosting av samme leverandør. Dermed bruker den standard serverinnstillinger.
- Hvis MTs støtte ikke hjalp, flytt til DreamHost
Mange ideer kjørte i tankene mine og en hel dag ble bortkastet. Få timer etter at jeg har fjernet nettstedet mitt fra CloudFlare, kaster nå WordPress en annen feilmelding. Nå står det "Informasjonskapsler er blokkert", selv om alle nettleserne mine er innstilt på å godta informasjonskapsler.
Fikset det Atlast!
Trinn 1:
I wp-config fjernet jeg disse linjene som inneholdt de hemmelige nøklene:
define ('AUTH_KEY' define ('SECURE_AUTH_KEY' define ('LOGGED_IN_KEY' define) Steg 2:
Lagret filen med UTF-8-koding (den ble vist som ANSI). Selv om dette kanskje ikke forårsaker problemet ... men jeg prøvde det bare.
Endelig kunne jeg logge inn på WordPress Admin Panel. Deretter genererte jeg nye sikkerhetsnøkler, logget av WordPress og logget inn igjen. Det funket!
Hva forårsaket problemet i utgangspunktet?
Mens de fleste innlegg på internett pekte på det nylig CloudFlare Plugin, var det ikke det i mitt tilfelle. Min gjetning er at Plesks sikkerhetskontroll (i endring nr. 2 ovenfor) brøt den, da jeg bare fikk logge på etter å ha fjernet de hemmelige nøklene fra wp-config.php. Selvfølgelig genererte jeg så nye sikkerhetsnøkler, oppdatert wp-config.php. Jeg koblet siden til CloudFlare på nytt og aktiverte plugin-modulen deres.
Heldigvis dukket ikke problemet opp så langt!
Moral av historien (sa jeg til meg selv): Ikke spill med innstillingene i Plesk hvis du ikke vet hva du gjør. Og gjør en endring om gangen, og det også bare hvis det er absolutt nødvendig, slik at du vet hvilke innstillinger som forårsaker et problem. Linux / Apache er ikke som Windows ... de er mer komplekse, i det minste for meg. Hvis dette innlegget hjalp deg, eller hvis du har flere innspill til å løse dette problemet, kan du dele tankene dine i kommentarfeltet nedenfor.
