Faqet e testimit të WordPress-it duhet të sigurohen gjithashtu
Faqet e testimit të WordPress-it nuk janë kopje të hedhura. Një faqe testimi është një kopje private testimi e faqes suaj të drejtpërdrejtë (produktive) WordPress. Ajo ju lejon të provoni përditësimet kryesore, përditësimet e shtojcave dhe temave, ndryshimet e dizajnit, shtojcat e reja, përmirësimet e PHP-së, format dhe arkëtimin, si dhe rregullimet e problemeve përpara se ato të ndikojnë te vizitorët. Por kur klononi një faqe të drejtpërdrejtë në testim, kopjoni gjithashtu llogaritë e përdoruesve të WordPress-it, të dhënat e klientëve, dorëzimet e formave, kredencialet e bazës së të dhënave, çelësat API, dobësitë e shtojcave dhe temave, dhe përmbajtjen private. Për shkak se faqet e testimit shpesh trajtohen si të përkohshme, ato marrin më pak vëmendje dhe bëhen një rrezik i panevojshëm sigurie.
Mënyra më e lehtë për një fillestar për të krijuar një faqe testimi është të përdorë mjetin e integruar të testimit të ofruesit të hostimit. Rrjedha tipike e punës është: hyni në panelin e hostimit, zgjidhni faqen e drejtpërdrejtë, gjeni opsionin Staging, Clone ose Copy Site, krijoni një kopje të skedarëve dhe bazës së të dhënave, kufizoni aksesin në mjedisin e testimit dhe konfirmoni që faqja e kopjuar funksionon. Gjithmonë krijoni një kopje rezervë aktuale të WordPress-it përpara klonimit ose vendosjes së ndryshimeve. Nëse e ndërtoni testimin manualisht, ju nevojitet një nëndomain i veçantë, skedarë të veçantë WordPress, një bazë të dhënash e veçantë, kredenciale të përditësuara të bazës së të dhënave, URL të përditësuara të faqes dhe kufizime aksesi. Konfigurimet manuale japin më shumë kontroll, por krijojnë më shumë mundësi për të lidhur bazën e gabuar të të dhënave ose për të ekspozuar detaje konfigurimi, kështu që nëse nuk jeni rehat me bazat e të dhënave dhe wp-config.php, përdorni një mjet hostimi ose punoni me një administrator me përvojë.
Pasi ekziston testimi, trajtojeni atë si një faqe interneti reale me një qëllim të kufizuar. Kufizoni aksesin në mënyrë që të mos jetë hapur i arritshëm. Kontrollet e zakonshme përfshijnë mbrojtjen me fjalëkalim HTTP, lejimin e IP-ve (duke lejuar vetëm adresa specifike interneti), rrjetet private ose VPN-të, dhe kontrollet e aksesit në nivel hostimi. Mos u mbështetni vetëm në faqen e hyrjes së WordPress-it, sepse faqet publike, skedarët, API-të dhe pikat fundore të shtojcave mund të jenë ende të arritshme. Gjithashtu, në WordPress shkoni te Settings > Reading dhe aktivizoni "Discourage search engines from indexing this site". Kjo zvogëlon mundësinë që përmbajtja e papërfunduar e testimit të shfaqet në rezultatet e kërkimit, por nuk është një kontroll sigurie dhe nuk i ndalon njerëzit ose botet me qëllime të këqija.
Shënoni kopjen si testim duke shtuar rreshtin `define( 'WP_ENVIRONMENT_TYPE', 'staging' );` në wp-config.php, mbi komentin `/* That's all, stop editing! Happy publishing. */`. Kjo ndihmon WordPress-in dhe softuerin e përputhshëm të njohë mjedisin, por nuk e mbron faqen në vetvete. Më e rëndësishme është të mos ripërdorni kredencialet e prodhimit. Përdorni fjalëkalime të veçanta të administratorit të WordPress-it, kredenciale të bazës së të dhënave, llogari SFTP ose SSH, çelësa API, kredenciale pagese, kredenciale emaili dhe webhooks. Pas klonimit, rishikoni wp-config.php, cilësimet e shtojcave dhe variablat e mjedisit për sekrete të prodhimit që faqja e testimit nuk i nevojiten. Hiqni të dhënat e panevojshme të klientëve si emrat, adresat e emailit, numrat e telefonit, adresat, porositë, dorëzimet e formave, të dhënat e anëtarësimit dhe shenjat e vërtetimit. Për një faqe e-commerce, mjaftojnë disa porosi testimi; për një faqe anëtarësimi, krijoni llogari testimi në vend që të kopjoni të dhënat reale të klientëve.
Një faqe e klonuar mund të vazhdojë të komunikojë me shërbimet e prodhimit. Kontrolloni nëse testimi mund të dërgojë email klientësh, të përpunojë pagesa, të përditësojë inventarin, të shkaktojë flukse pune marketingu, të dërgojë mesazhe SMS ose të dorëzojë webhooks të prodhimit. Përdorni kredenciale pagese testimi ose sandbox, ridrejtoni ose bllokoni emailin dalës dhe zëvendësoni çelësat API të prodhimit dhe destinacionet e webhooks. Bëjeni këtë herët, sepse detyrat e planifikuara mund të fillojnë të ekzekutohen sapo të krijohet kopja e testimit. Kriptoni trafikun e testimit me HTTPS dhe një certifikatë të vlefshme TLS; kjo mbron kredencialet dhe të dhënat e testimit gjatë transmetimit, por nuk zëvendëson vërtetimin, përditësimet ose monitorimin. Mbani të përditësuar bërthamën e WordPress-it, shtojcat, temat, PHP-në dhe softuerin e serverit, dhe hiqni shtojcat dhe temat që nuk nevojiten më, sepse softueri joaktiv mund të përmbajë ende skedarë që janë të arritshëm nga uebi.
Jepini çdo personi vetëm aksesin e nevojshëm për detyrën e tij. Një recensues përmbajtjeje mund të ketë nevojë vetëm për leje Redaktori; një kontraktor që teston një formë mund të mos ketë nevojë për akses në hostim. Rishikoni gjithashtu llogaritë e klonuara të përdoruesve, sepse llogaritë e vjetra të agjencive, kontraktorëve ose stafit mund të ekzistojnë ende në bazën e të dhënave të kopjuar. Udhëzuesi i Sucuri për rolet e përdoruesve të WordPress-it dhe privilegjin minimal shpjegon se si të zvogëloni lejet e panevojshme të llogarive. Shtoni testimin në inventarin tuaj të faqeve dhe monitoroni për ndryshime të papritura skedarësh, llogari të reja administratori, hyrje të dështuara, tregues malware dhe akses publik të papritur. Sucuri ofron monitorim faqesh dhe skanim malware, dhe skaneri i tij SiteCheck mund të inspektojë faqet e arritshme publikisht për tregues të njohur malware dhe çështje të caktuara sigurie. Mjediset e testimit të arritshme nga interneti mund të përfitojnë gjithashtu nga një mur mbrojtës faqesh për të filtruar trafikun me qëllime të këqija përpara se të arrijë në WordPress.
Një rrjedhë e sigurt pune testimi ka tri faza. Përpara testimit: krijoni dhe verifikoni një kopje rezervë të prodhimit, kufizoni aksesin në testim, dekurajoni indeksimin nga motorët e kërkimit, hiqni të dhënat e panevojshme të klientëve, zëvendësoni kredencialet dhe integrimet e prodhimit, dhe çaktivizoni pagesat dhe emailet reale. Gjatë testimit: ndryshoni një komponent kryesor në një kohë, testoni hyrjen, format, kërkimin, navigimin dhe arkëtimin, kontrolloni paraqitjet në desktop dhe celular, rishikoni gabimet dhe regjistrat, dhe konfirmoni që nuk u dërguan komunikime reale me klientët. Përpara vendosjes: krijoni një kopje rezervë tjetër të prodhimit, identifikoni saktësisht se çfarë do të kopjohet, rishikoni ndryshimet midis testimit dhe prodhimit, dokumentoni një proces rikthimi, aplikoni ndryshimet e miratuara dhe testoni veçoritë kritike në prodhim.
Një nga rreziqet më të mëdha të testimit është mbishkrimi i të dhënave më të reja të prodhimit kur shtyni testimin në prodhim. Imagjinoni një faqe e-commerce të kopjuar në testim të hënën. Klientët vazhdojnë të bëjnë porosi në faqen e drejtpërdrejtë gjatë javës. Të premten, dikush shtyn të gjithë bazën e të dhënave të testimit të së hënës përsëri në prodhim, dhe ato porosi më të reja humbasin. I njëjti problem mund të ndikojë në llogaritë e klientëve, dorëzimet e formave, komentet, rezervimet, inventarin dhe aktivitetin e anëtarësimit. Përpara se të përdorni një mjet Push to Production, kuptoni nëse ai do të zëvendësojë skedarët, tabelat e bazës së të dhënave ose të gjithë faqen. Për ndryshime të vogla dizajni, mund të jetë më e sigurt të lëvizni vetëm skedarët e nevojshëm ose të rikrijoni cilësimin në prodhim.
Fshini një faqe testimi kur ajo nuk ka më një qëllim të qartë. Përpara fshirjes: konfirmoni që ndryshimet e miratuara arritën në prodhim, ruani çdo kod ose dokumentacion të kërkuar, fshini skedarët dhe bazat e të dhënave të testimit, hiqni rekordin DNS, revokoni kredencialet dhe çelësat API të testimit, hiqni përdoruesit e përkohshëm dhe konfirmoni që URL-ja e testimit nuk ekspozon më përmbajtje. Nëse testimi është i përhershëm, përfshijeni atë në proceset tuaja normale të korrigjimit, rishikimit të aksesit, monitorimit, kopjeve rezervë dhe reagimit ndaj incidenteve. Një faqe testimi absolutisht mund të hakohet: një faqe testimi e arritshme publikisht është ende një faqe interneti, dhe softueri i cenueshëm, kredencialet e dobëta ose skedarët e ekspozuar mund të abuzohen pavarësisht nëse etiketohet si testim apo prodhim. Testimi normalisht nuk duhet të shfaqet në Google, sepse mund të ekspozojë faqe të papërfunduara ose përmbajtje të dyfishuar. Bëni kopje rezervë për çdo gjë në testim që do të ishte e vështirë për t'u rikrijuar, por gjithmonë bëni kopje rezervë të prodhimit përpara klonimit, vendosjes ose ndryshimit të bazës së tij të të dhënave.
Një faqe testimi WordPress ju lejon të testoni përditësimet dhe ndryshimet pa eksperimentuar në faqen e drejtpërdrejtë. Një mjedis i sigurt testimi duhet të jetë i ndarë nga prodhimi, i mbrojtur nga aksesi publik, i pastruar nga të dhënat e panevojshme të ndjeshme, i shkëputur nga shërbimet e drejtpërdrejta, i monitoruar dhe i hequr kur nuk nevojitet më. Kombinoni një rrjedhë të kontrolluar pune testimi me kopje rezervë të faqes, monitorim sigurie dhe një mur mbrojtës faqesh për mbrojtje më të fortë. Për lexuesit që preferojnë të mos menaxhojnë sigurinë e testimit me dorë, hostet e menaxhuar të WordPress-it si AEU Hosting përfshijnë mjedise testimi, kopje rezervë automatike, certifikata SSL dhe forcim sigurie si pjesë e platformës, gjë që heq disa nga hapat manualë të përshkruar më sipër.