Bijota „WordPress“ „Reauth = 1“ „Administratoriaus skydelio prisijungimo peradresavimo ciklo problema šį kartą mane šiek tiek pakeitė, ir šiame įraše dalinuosi informacija apie tai, kaip jį ištaisiau. Aš jokiu būdu nesu „Apache“, „Linux“ ar „WordPress“ žinių ekspertas, tačiau čia esanti informacija gali padėti kitiems, susidūrusiems su tokia pačia situacija.
Vienas iš trijų konfigūracijos pakeitimų, kuriuos padariau prieglobos valdymo skyde, sukėlė „WordPress Admin“ prisijungimo kilpą.
1 pakeitimas
Prijungiau savo domeną prie „CloudFlare“ ir įdiegiau „CloudFlare WordPress“ papildinį. CDN veikė puikiai.
2 pakeitimas
„Plesk“ valdymo skydelyje prisijungiau prie savo „WordPress“ diegimo. Pleskas šalia mano „WordPress“ diegimo parodė raudoną ženklą, kuris spustelėjęs paprašė manęs patikrinti mano „WordPress“ diegimo saugumą. Jis sakė:
Peržiūrėkite pasirinktų „WordPress“ diegimų saugos patikrinimo rezultatus. Jei kai kurie duomenys neišlaikė saugumo patikros, galite pasirinkti šiuos duomenis iš sąrašo ir sustiprinti jų saugumą.
Iš sąrašo pasirenku saugos klavišus ir spustelėkite „Saugus“.
Apsaugos rakto aprašymas sako:
„WordPress“ naudoja saugos raktus (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY ir NONCE_KEY), kad užtikrintų geresnį vartotojo slapukuose saugomos informacijos šifravimą…. Jei saugos patikrinimo atlikti nepavyko ir nusprendėte apsaugoti „WordPress“ diegimą, bus sukurti ir pridėti tinkami saugos raktai jūsų „WordPress“ diegimui.
3 pakeitimas
Pradėjo „nginx“ nuo paslaugų valdymo Pleske.
Prisijungimo kilpa
Kitą kartą, kai bandžiau prisijungti prie „WordPress“, jis tiesiog nukreipė į „Reauth = 1“ puslapį. Jei sąmoningai įvedžiau neteisingą slaptažodį, jis pasakė, kad slaptažodis neteisingas. Taigi, autentifikavimo medžiaga veikė gerai, tačiau dėl tam tikrų priežasčių ji buvo nukreipta į „Reauth“ URL, kai buvo naudojami teisingi kredencialai. Čia yra sąrašas dalykų, kuriuos aš išbandžiau, ir nė vienas iš jų (išskyrus toliau pateiktus 15 numerius) nepadėjo.
- Visiškai išvalė žiniatinklio naršyklės talpyklą ir išbandė skirtingas naršykles.
- Sustabdytas „nginx“, kaip skaityta apie talpyklos kaupimą (nginx.conf)
- Išjungtas „CloudFlare“ papildinys per „Plesk“, nes kai kuriems vartotojams tai nutraukė „WP Admin“ funkcijas
- Išjungė VISUS papildinius ir iš naujo paleido serverį
- Optimizuota ir suremontuota duomenų bazė per „PhpMyAdmin“
- Patvirtintas svetainės URL „wp_options“ lentelėje. Tai buvo teisinga
- Patikrinti wp-config failo, wp-admin ir wp-įtrauktų katalogų leidimai
- Pridėta WP_HOME ir WP_SITEURL į wp-config.php
- Sugeneruoti nauji SALT arba Secret raktų kodai ir įtraukti į wp-config.php
- Suaktyvino Dvidešimt šešiolikos temą
- Paskelbta „WordPress“ forumuose ir visiškai jokio atsakymo
- Mano svetainė atkurta iš naujausios „VaultPress“ atsarginės kopijos
- Įgalintas „CloudFlare“ kūrimo režimas
- Nustatykite „CloudFlare PageRule“ taip, kad apeitų „Admin“ puslapių talpyklą (WP *)
- Atskyriau mano svetainę iš „CloudFlare“
Be to, kas buvo daroma, buvo dar daug kitų dalykų, iš kurių kai kurie gali būti nereikšmingi. Aš rimtai svarstiau šias galimybes:
- Kreipkitės į „CloudTech“ profesionalią pagalbą (per „MT Admin Panel“) už 79 USD, tačiau pataisymas negarantuojamas.
- Iš naujo nustatyti „Plesk DV“ numatytuosius nustatymus. Tačiau viską atkurti prireiktų daug laiko.
- Neatidėliotinos pagalbos atkūrimo užklausa, vėlgi už 79 USD. Atkuriamas tik svetainės turinys, ką jau padariau iš „VaultPress“.
- Išmeskite serverį ir pereikite prie to paties teikėjo valdomo „Premium WordPress Hostingas“. Tokiu būdu jis naudoja numatytuosius serverio nustatymus.
- Jei MT palaikymas nepadėjo, pereikite į „DreamHost“
Mano galvoje kilo daugybė idėjų, o viena diena buvo iššvaistyta. Po kelių valandų nuo mano „CloudFlare“ atskyrimo, dabar „WordPress“ pateikia kitą klaidos pranešimą. Dabar sakoma „Slapukai blokuojami“, nors visos mano interneto naršyklės yra pritaikytos priimti slapukus.
Pataisyta „Atlast“!
1 žingsnis:
Iš wp-config pašalinau šias eilutes, kuriose buvo slapti raktai:
apibrėžti ('AUTH_KEY' apibrėžti ('SECURE_AUTH_KEY' apibrėžti ('LOGGED_IN_KEY' apibrėžti ('NONCE_KEY' apibrėžti ('AUTH_SALT' apibrėžti ('SECURE_AUTH_SALT' apibrėžti ('LOGGED_IN_SALT' apibrėžti ('NONCE_SALT') 2 žingsnis:
Įrašyta byla su UTF-8 kodavimu (ji rodoma kaip ANSI). Nors tai galbūt ir nekelia problemos ..., bet aš tiesiog ją išbandžiau.
Pagaliau galėjau prisijungti prie „WordPress“ administratoriaus pulto. Tada sugeneravau naujus saugos raktus, atsijungiau nuo „WordPress“ ir vėl prisijungiau. Pavyko!
Kas pirmiausia sukėlė problemą?
Nors dauguma žinučių internete nurodė naujausią „CloudFlare“ papildinį, mano atveju tai nebuvo. Spėju, kad Plesko saugumo patikrinimas (2 pakeitime aukščiau) jį sulaužė, nes tik pašalinus slaptuosius raktus iš wp-config.php man buvo leista prisijungti. Žinoma, tada sugeneravau naujus saugos raktus, atnaujinau wp-config.php. Tada aš vėl prijungiau savo svetainę prie „CloudFlare“ ir įgalinau jų papildinį.
Laimei, problema dar neatsirado!
Pasakojimo moralas (sakiau sau): Nežaidi su „Plesk“ nustatymais, jei nežinai, ką darai. Ir atlikite vieną pakeitimą vienu metu, taip pat tik tuo atveju, jei tai tikrai būtina, kad žinotumėte, kuris nustatymas sukelia problemą. „Linux“ / „Apache“ nėra tokie kaip „Windows“ ... jie yra sudėtingesni, bent jau man. Jei šis įrašas jums padėjo ar turite papildomų įmokų, kaip išspręsti šią problemą, prašau pasidalinti savo mintimis žemiau esančiame komentarų skyriuje.
