Pelätty WordPress "Reauth = 1" Järjestelmänvalvojan paneelin sisäänkirjautumisen uudelleenohjauksen ongelma hammastutti minut tällä kertaa, ja jaan tässä viestissä tietoja korjaamisesta. En ole mitenkään Apache-, Linux- tai WordPress-tavaroiden asiantuntija, mutta täällä olevat tiedot voivat auttaa muita, jotka joutuvat kohtaamaan saman tilanteen.
Yksi kolmesta isännöinnin ohjauspaneelissa tekemästä kokoonpanomuutoksesta aiheutti WordPress Admin -sisäänkirjautumissilmukan.
Vaihda 1
Liitin verkkotunnukseni CloudFlare -sovellukseen ja asensin CloudFlare WordPress -laajennuksen. CDN toimi hyvin.
Vaihda 2
Yhdistin Plesk-ohjauspaneelin WordPress-asennukseen. Plesk osoitti punaisen kyltin lähellä WordPress-asennusta, joka napsautettaessa pyysi minua tarkistamaan WordPress-asennukseni suojauksen. Se sanoi:
Tarkastele valittujen WordPress-asennusten turvatarkistuksen tuloksia. Jos tietyt tiedot eivät läpäisseet turvatarkastuksia, voit valita nämä tiedot luettelosta ja parantaa niiden suojausta.
Valitsin luettelosta suojausavaimet ja napsautin Suojattu.
Suojausavaimen kuvauksessa sanotaan:
WordPress käyttää suojausavaimia (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY ja NONCE_KEY) varmistaakseen käyttäjän evästeisiin tallennettujen tietojen paremman salauksen. Jos turvatarkastus epäonnistuu ja päätät suojata WordPress-asennuksen, hyvät suojausavaimet luodaan ja lisätään WordPress-asennukseen.
Vaihda 3
Aloitti nginx Palvelunhallinnasta Pleskissä.
Sisäänkirjautumissilmukka
Seuraavan kerran kun yritin kirjautua sisään WordPressiin, se vain ohjautui "Reauth = 1" -sivulle. Jos kirjoitin tahallisesti väärän salasanan, se sanoi, että salasana oli väärä. Joten autentikointiasiat toimivat hyvin, mutta jostain syystä ne uudelleenohjattiin Reauth URL-osoitteeseen, kun oikeita valtuustietoja käytettiin. Tässä on luettelo asioista, joita yritin, ja yksikään niistä (paitsi, voi olla # 15 alla) ei auttanut.
- Tyhjennyt selaimen välimuisti kokonaan ja kokeillut erilaisia selaimia.
- Pysäytetty nginx, lukemalla välimuistiongelmasta (nginx.conf)
- Poistettu käytöstä CloudFlare-laajennus Pleskin kautta, koska se rikkoi WP-järjestelmänvalvojan ominaisuuksia joillekin käyttäjille
- Poista käytöstä kaikki laajennukset ja käynnisti palvelimen uudelleen
- Tietokannan optimointi ja korjaus PhpMyAdminin kautta
- Vahvistettu sivuston URL-osoite taulukossa wp_options. Se oli oikein
- Vahvistetut käyttöoikeudet wp-config-tiedostoon, wp-admin ja wp-sisältyy hakemistoihin
- Lisätty WP_HOME ja WP_SITEURL wp-config.php-tiedostoon
- Luo uusia SALT- tai Secret-avainkoodeja ja lisäsi tiedostoon wp-config.php
- Aktivoi 22-teema
- Lähetetty WordPress-foorumeilla, eikä mitään vastausta
- Palautin sivustoni viimeisimmästä VaultPress-varmuuskopiosta
- Aktivoitu kehitystila CloudFlaressa
- Aseta CloudFlare PageRule ohittamaan järjestelmänvalvojan välimuistin tallennus (WP- *)
- Omakotini sivustoni CloudFlaresta
Edellä esitetyn lisäksi tein monia muita asioita, joista jotkut saattavat olla triviaalia. Harkitsin vakavasti näitä vaihtoehtoja:
- Pyydä CloudTech Professional -apua (MT Admin Panelin kautta) 79 dollarilla, mutta korjausta ei taata.
- Palauta Plesk DV: n oletusasetukset. Mutta kaiken palauttaminen vie paljon aikaa.
- Hätätilan palautuspyyntö, jälleen 79 dollaria. Vain sivuston sisältö palautetaan, minkä olen jo tehnyt VaultPressistä.
- Hylkää palvelin ja siirry saman palveluntarjoajan hallinnoimaan Premium WordPress Hosting -palveluun. Tällöin se käyttää palvelimen oletusasetuksia.
- Jos MT: n tuki ei auttanut, siirry DreamHostiin
Mielessäni juoksi paljon ideoita ja yksi täysi päivä hukkui. Muutaman tunnin kuluttua sivustoni irroittamisesta CloudFlaresta, nyt WordPress lähettää eri virheilmoituksen. Nyt sanotaan "Evästeet on estetty", vaikka kaikki selaimeni on asetettu hyväksymään evästeet.
Korjattu Atlast!
Vaihe 1:
Poistin wp-config-tiedostosta nämä rivit, jotka sisälsivät salaiset avaimet:
määrittele ('AUTH_KEY' määrittele ('SECURE_AUTH_KEY' määrittele ('LOGGED_IN_KEY' määrittele ('NONCE_KEY' määrittele ('AUTH_SALT' määrittele ('SECURE_AUTH_SALT' määrittele ('LOGGED_IN_SALT' määrittele ('NONCE_SALT') Vaihe 2:
Tallensi tiedoston UTF-8-koodauksella (se näkyi nimellä ANSI). Vaikka tämä EI ehkä aiheuta ongelmaa ..., mutta yritin vain.
Viimeinkin pystyin kirjautumaan WordPressin hallintapaneeliin. Sitten tuotin uusia suojausavaimia, kirjauduin ulos WordPressistä ja kirjauduin takaisin. Se toimi!
Mikä aiheutti ongelman ensinnäkin?
Vaikka suurin osa Internetin viesteistä viittasi äskettäiseen CloudFlare-laajennukseen, niin se ei ollut minun tapauksessani. Luulen, että Pleskin tietoturvatarkistus (muutoksessa 2 yllä) rikkoi sen, koska vasta kun olin poistanut salaiset avaimet wp-config.php: stä, sain minun kirjautua sisään. Tietenkin, sitten tuotin uusia suojausavaimia, päivitetty wp-config.php. Sitten liitin sivustoni uudelleen CloudFlareen ja sallin heidän laajennuksen.
Onneksi ongelma ei ilmennyt toistaiseksi!
Tarinan moraali (sanoin itselleni): Älä pelaa Pleskin asetusten kanssa, jos et tiedä mitä teet. Tee myös yksi muutos kerrallaan ja sekin vain, jos se on ehdottoman välttämätöntä, jotta tiedät, mikä asetus aiheuttaa ongelman. Linux / Apache ei ole kuin Windows ... ne ovat monimutkaisempia, ainakin minulle. Jos tämä viesti auttoi sinua tai sinulla on lisäpanoksia tämän ongelman korjaamiseen, kerro mielipiteesi alla olevassa Kommentit-osiossa.
