WordPressi „Reauth = 1” sisselogimissilmus ja viga „Küpsised on blokeeritud”. Kuidas ma selle parandasin?

Kardetud WordPressi "Reauth = 1" administraatori paneeli sisselogimise ümbersuunamise silmuse probleem hammustas mind seekord ja jagan selles postituses teavet selle parandamise kohta. Ma pole mingil juhul Apache, Linuxi või WordPressi asjatundja, kuid siin olev teave võib aidata teisi, kes sama olukorraga kokku puutuvad.

Üks kolmest konfiguratsioonimuudatusest, mille ma hostingu juhtpaneelil tegin, põhjustas WordPressi administraatori sisselogimissilmuse.

1. muudatus

Lisasin oma domeeni CloudFlare külge ja installisin CloudFlare WordPressi pistikprogrammi. CDN töötas suurepäraselt.

2. muudatus

Pleski juhtpaneelil ühendasin oma WordPressi installimisega. Plesk näitas minu WordPressi installi lähedal punast silti, millel klõpsamisel paluti mul kontrollida minu WordPressi installi turvalisust. Seal oli kirjas:

Vaadake valitud WordPressi installide turvakontrolli tulemusi. Kui mõned andmed ei läbinud turvakontrolli, saate need andmed loendist valida ja nende turvalisust tugevdada.

Valin loendist turvavõtmed ja klõpsasin turvatud.

Turvavõtme kirjeldus ütleb:

WordPress kasutab turvavõtmeid (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY ja NONCE_KEY), et tagada kasutaja küpsistes salvestatud teabe parem krüptimine. Kui turvakontroll nurjus ja otsustate WordPressi installimise turvaliseks muuta, genereeritakse ja lisatakse teie WordPressi installimiseks head turvavõtmed.

3. muudatus

Alustas nginxi teenusehaldusest Pleskis.

Sisselogimissilmus

Järgmine kord, kui proovisin WordPressisse sisse logida, suunati see lihtsalt uuesti lehele "Reauth = 1". Kui ma trükkisin tahtlikult vale parooli, siis öeldi, et parool on vale. Niisiis, autentimise värk töötas kenasti, kuid õigete mandaatandmete kasutamisel suunati see mingil põhjusel Reauthi URL-i. Siin on nimekiri asjadest, mida proovisin, ja ükski neist (välja arvatud allpool võib olla nr 15) ei aidanud.

1. Tühjendas veebibrauseri vahemälu täielikult ja proovis erinevaid brausereid.
2. Peatatud nginx, lugedes vahemällu salvestamise küsimust (nginx.conf)
3. Pleski kaudu keelatud CloudFlare'i pistikprogramm, kuna see purustas mõne kasutaja jaoks WP Admini funktsioonid
4. Keelas KÕIK Pluginad ja taaskäivitas serveri
5. Andmebaasi optimeeriti ja parandati PhpMyAdmini kaudu
6. Kinnitatud saidi URL tabelis wp_options. See oli õige
7. Wp-konfiguratsioonifaili, wp-admin ja wp-sisaldab kataloogide kinnitatud õigused
8. Wp_HOME ja WP_SITEURL on lisatud wp-config.php
9. Loodud uued SALT või Secret võtme koodid ja lisatud wp-config.php
10. Aktiveeris teema Kaksteist kuusteist
11. Postitatud WordPressi foorumites ja sellele pole mingit vastust
12. Taastasin minu saidi kõige uuemast VaultPressi varundusest
13. CloudFlare'is on arendusrežiim lubatud
14. Määrake CloudFlare PageRule administraatorilehtede vahemälust (WP *)
15. Eraldasin minu saidi CloudFlare'ist

Lisaks ülaltoodule tegin veel palju muid asju, millest mõned võivad olla triviaalsed. Kaalusin tõsiselt järgmisi võimalusi:

1. Otsige CloudTechi professionaalset abi (MT administraatori paneeli kaudu) 79 dollariga, kuid parandus pole garanteeritud.
2. Lähtestage Plesk DV vaikeseaded. Kuid kõige taastamine võtab palju aega.
3. Hädaolukorra taastamise taotlus, jälle 79 dollari eest. Taastatakse ainult saidi sisu, mida ma juba VaultPressist tegin.
4. Visake server ära ja minge sama teenusepakkuja hallatavale Premium WordPress Hostingile. Sellega kasutab see serveri vaikeseadeid.
5. Kui MT tugi ei aidanud, liikuge DreamHosti

Minu peas jooksis palju ideid ja üks terve päev läks raisku. Mõni tund pärast minu saidi CloudFlare'ist eemaldamist viskab WordPress nüüd teistsuguse veateate. Nüüd öeldakse "Küpsised on blokeeritud", ehkki kõik minu veebibrauserid on küpsiseid vastu võtma.

Parandatud Atlast!

Samm 1:

Wp-configist eemaldasin need read, mis sisaldasid salajasi võtmeid:

 define ('AUTH_KEY' define) '' SECURE_AUTH_KEY 'define (' LOGGED_IN_KEY 'define (' LOGGED_IN_KEY 'define) 

2. samm:

Salvestati fail UTF-8 kodeeringuga (see kuvati kui ANSI). Kuigi see ei pruugi probleemi põhjustada ... aga proovisin seda lihtsalt.

Lõpuks suutsin sisse logida WordPressi administraatori paneeli. Seejärel genereerisin uued turvavõtmed, logisin WordPressist välja ja tagasi sisse. See töötas!

Mis probleemi ennekõike põhjustas?

Kui enamik Interneti postitusi osutas hiljutisele CloudFlare'i pistikprogrammile, siis minu puhul see polnud. Ma arvan, et Pleski turvakontroll (2. muudatuses ülal) rikkus selle, kuna alles pärast salajaste võtmete eemaldamist wp-config.php-st lubati mul sisse logida. Muidugi genereerisin siis uued turvavõtmed, värskendasin wp-config.php. Seejärel kinnitasin oma saidi uuesti CloudFlare'i ja lubasin nende pistikprogrammi.

Õnneks ei ilmnenud probleemi siiani!

Loo moraal (ütlesin endale): Ärge mängige Pleski seadetega, kui te ei tea, mida teete. Ja tehke üks muudatus korraga ja seda ka ainult siis, kui see on tingimata vajalik, et saaksite teada, milline seade põhjustab probleemi. Linux / Apache pole nagu Windows ... nad on keerukamad, vähemalt minu jaoks. Kui see postitus aitas teid või kui teil on selle probleemi lahendamiseks täiendavaid sisendeid, palun jagage oma mõtteid allpool olevas kommentaaride jaotises.