Ang isang customer ay nagbukas ng isang pahina ng account at nakita ang pangalan ng ibang tao. Ang pag-login ay maaaring gumagana ayon sa disenyo. Maaaring nai-save ng isang nakabahaging cache ang maling pahina at naipadala ito sa susunod na bisita.
Ang pag-cache ay ginagawang mas mabilis ang WordPress sa pamamagitan ng muling paggamit ng trabaho. Ngunit ang isang pahina na binuo para sa isang tao ay nangangailangan ng iba't ibang mga panuntunan mula sa isang pampublikong post sa blog. Ipinapakita ng gabay na ito kung paano suriin ang hangganang iyon nang hindi pinapatay ang bawat feature ng bilis.
Imapa ang mga cache na ginagamit ng iyong site
Magsimula sa browser, pagkatapos ay ang CDN, hosting cache, page-cache plugin at object cache. Ang CDN ay isang network na naghahatid ng nilalaman na malapit sa mga bisita. Ang isang object cache ay nag-iimbak ng data na ginagamit ng app; ito ay hindi katulad ng isang naka-save na buong pahina.
Isulat kung sino ang nagmamay-ari ng bawat layer. Ang dalawang tool ay maaaring parehong magmukhang tama sa paghihiwalay habang ang isang malawak na panuntunan ay na-override ang isa pa. Ang isang "cache everything" na panuntunan ay nararapat na masusing pagsusuri sa isang store o membership site.
Ang aming WordPress gabay sa bilis sumasaklaw sa bahagi ng pagganap. Magdagdag ng pagsuri sa privacy sa parehong trabaho upang hindi maitago ng mga speed gain ang isang data leak.
Magpasya kung aling mga tugon ang dapat manatiling pribado
Listahan ng mga page na nagpapakita ng mga pangalan, order, address, pribadong pag-download, mga detalye ng account o custom na presyo. Isama ang mga API call na naglo-load ng data na ito pagkatapos magbukas ng page.
Ang mga pahina ng cart, checkout at account ay madalas na nangangailangan ng mga panuntunan sa pag-bypass ng shared-cache. Gawin din ang mga na-authenticate na tugon at mga page na nakadepende sa isang pribadong session. Suriin ang aktwal na mga ruta na ginagamit ng iyong mga plugin; maaaring may ibang URL ang custom na page ng account.
Ang isang pampublikong pahina ay maaari pa ring mag-load ng isang pribadong widget. Halimbawa, ang shell ng pahina ay maaaring ligtas na i-cache habang ang buod ng order nito ay hindi. Siyasatin ang tugon na naglalaman ng pribadong data, hindi lang ang address bar.
Gamitin ang aming WooCommerce checklist ng seguridad upang isama ang mga daloy ng account at pag-checkout sa pagsusuri.
Unawain ang tatlong kapaki-pakinabang na mga direktiba ng cache
Ang Cache-Control header ay nagsasabi sa mga katugmang cache kung paano pangasiwaan ang isang tugon. Ang "Pribado" ay hindi kasama ang mga nakabahaging cache ngunit maaaring payagan ang isang cache ng browser. Sinasabi ng "No-store" sa mga cache na huwag panatilihin ang tugon. Ang "No-cache" ay nagbibigay-daan sa storage ngunit nangangailangan ng pagpapatunay bago muling gamitin. Hindi ito nangangahulugang "huwag iligtas ito."
Ang mga kahulugang ito at pag-uugali na partikular sa provider ay nakadokumento sa Gabay sa pagkontrol ng cache ni Cloudflare. Suriin din ang iyong host at mga panuntunan sa CDN. Ang isang header lamang ay hindi patunay kung ano ang ginagawa ng buong stack.
Para sa mga sensitibong page, gumamit ng sinasadyang patakaran para sa parehong browser at mga nakabahaging cache. Pagkatapos ay subukan ang tugon. Panatilihin ang mga pagsusuri sa pagpapatotoo sa lugar: ang mga header ng cache ay hindi makakapagpasya kung sino ang maaaring tumingin ng isang order.
Magpatakbo ng dalawang-account na pagsubok
Lumikha ng dalawang pagsubok na customer na may malinaw na magkaibang dummy data. Gumamit ng hiwalay na mga profile ng browser upang manatiling magkahiwalay ang cookies. Ang ikatlong profile ay dapat manatiling naka-log out.
- Mag-sign in bilang customer A at buksan ang page ng account nang maraming beses.
- Buksan ang parehong ruta bilang customer B at ihambing ang resulta.
- Hilingin ang ruta habang naka-log out.
- Ulitin pagkatapos ng cache purge at muli pagkatapos uminit ang cache.
- Tingnan ang parehong nakikitang pahina at ang mga tugon ng network na pumupuno dito.
Walang pribadong pangalan, order o address ang dapat tumawid sa pagitan ng mga session na ito. Ulitin gamit ang isang cart, isang nag-expire na login at isang pag-download na protektado ng password. Gumamit ng mga pagsubok na order, hindi totoong mga tala ng customer.
Ang aming gabay sa seguridad ng session ipinapaliwanag kung bakit mahalaga ang cookies at pag-uugali sa pag-logout dito.
Isakatuparan ang mga ideyang ito.
Mula sa isang partikular na pag-aayos hanggang sa buong website, tutulungan ka naming linawin ang saklaw at maisagawa ito.
Pag-usapan ang website koAdvanced na Mga Solusyon sa Seguridad ng WordPressIbahagi ang iyong mga layunin. Karaniwan kaming tumutugon sa loob ng 4 na oras na may mga tanong at praktikal na susunod na hakbang.
Suriin kung ano talaga ang inihatid ng cache
Hilingin sa iyong developer na siyasatin ang mga header ng tugon at status ng cache. Ang isang hindi inaasahang cache na hit sa isang pribadong tugon ay nangangailangan ng pagsisiyasat. Ang isang cache miss ay hindi sapat upang patunayan ang kaligtasan; ang susunod na kahilingan ay maaaring isang hit.
Subukan gamit ang parehong CDN at hosting setup bilang ang live na site. Kung walang CDN ang pagtatanghal ng dula, hindi sasaklawin ng mga resulta nito ang edge caching. Isama pagtatanghal ng mga pananggalang at isang maliit, kinokontrol na live check.
Panatilihin ang isang talaan ng ruta, estado ng gumagamit, inaasahang pag-uugali at resulta. Ulitin ang mga pagsusuring ito pagkatapos ng pagbabago ng cache-plugin, isang bagong feature ng membership o isang paglipat ng pagho-host.
Ano ang gagawin kung nalantad ang data
Ihinto ang nakabahaging pag-cache sa mga apektadong ruta at i-purge ang mga nakaimbak na tugon sa bawat nauugnay na layer. Panatilihin ang sapat na ebidensya upang maunawaan kung aling data ang inihatid at kung kailan. Ayusin ang panuntunan, muling suriin, at suriin kung sino ang maaaring naapektuhan.
Ang pagpapalit ng header ay hindi maaasahang mag-alis ng mga lumang kopya na nakaimbak na sa ibang lugar. Sundin ang mga hakbang sa aming gabay sa pagtugon sa insidente kung ang isyu ay nagsasangkot ng data ng customer.
Ang mga pampublikong post at static na asset ay maaari pa ring makinabang mula sa pag-cache. Para sa tulong sa pagsuri sa hangganan, ang aming serbisyo sa pag-optimize ng bilis maaaring suriin ang pagganap kasabay ng pag-uugali ng pribadong pahina.
Mga madalas itanong
Dapat ko bang i-off ang lahat ng pag-cache sa isang WordPress na tindahan?
Kadalasan hindi. Maaari pa ring i-cache ang pampublikong nilalaman at mga static na asset. Suriin ang mga pribadong page, session at mga tugon sa API nang hiwalay.
Pinipigilan ba ng walang-cache ang pag-imbak ng isang pahina?
Hindi. Pinapayagan nito ang pag-imbak ngunit nangangailangan ng pagpapatunay bago muling gamitin. Ang No-store ay ang direktiba na ginagamit upang maiwasan ang pag-iimbak.
Sapat ba ang naka-log-out na browser upang subukan ang privacy ng cache?
Hindi. Subukan ang dalawang magkahiwalay na user account at isang naka-log-out na session. Suriin ang parehong malamig at mainit na mga estado ng cache.
Ang pag-purging ba ng cache ay nag-aayos ng masamang panuntunan?
Hindi. Ang pag-purge ay nag-aalis ng mga nakaimbak na kopya, ngunit ang parehong panuntunan ay maaaring mag-imbak muli ng pribadong data. Iwasto ang patakaran at muling subukan ito.
