WordPress ei perustu perinteiseen serveripuolen sessioarkkitehtuuriin. Se ei käytä PHP:n $_SESSION-mekanismia oletuksena, eikä se ylläpidä käyttäjäkohtaisia tiloja muistissa jokaisen pyynnön välillä. Sen sijaan WordPress toimii pääosin session-less-periaatteella: jokainen HTTP-pyyntö käsitellään itsenäisesti, ja käyttäjän tila määritellään evästeiden, tietokannan ja tokenien avulla.
Tämä arkkitehtuuri on yksi WordPressin keskeisistä suunnitteluratkaisuista. Se tekee järjestelmästä yksinkertaisen, skaalautuvan ja helpon hostata, mutta tuo mukanaan myös tiettyjä rajoitteita ja suunnittelukompromisseja.
Mitä session-less tarkoittaa käytännössä
Session-less tarkoittaa sitä, että:
– palvelin ei pidä aktiivista muistissa olevaa sessiota käyttäjälle
– jokainen pyyntö sisältää kaiken tarvittavan tunnistustiedon
– käyttäjän tila haetaan evästeiden ja tietokannan perusteella
WordPressissä kirjautuminen toimii näin:
-
Käyttäjä kirjautuu sisään
-
WordPress luo autentikointievästeen
-
Jokaisella pyynnöllä eväste tarkistetaan
-
Käyttäjän tiedot haetaan tietokannasta
Palvelin ei siis säilytä erillistä sessio-oliota muistissa, kuten monissa perinteisissä PHP-sovelluksissa.
Miksi WordPress on rakennettu näin
WordPress syntyi aikana, jolloin:
– jaettu hosting oli normi
– palvelinresurssit olivat rajalliset
– skaalaus tarkoitti yksinkertaisuutta
Session-less-arkkitehtuuri tarjoaa:
1. Helppo skaalaus
Koska sessiot eivät ole sidottuja tiettyyn palvelimeen, pyyntö voidaan käsitellä millä tahansa instanssilla. Tämä mahdollistaa:
– load balancingin
– autoskaalauksen
– CDN- ja edge-arkkitehtuurit
Ei tarvita sticky session -ratkaisuja tai keskitettyä session storea.
2. Yksinkertainen hosting
Jaetuissa hosting-ympäristöissä:
– ei tarvitse konfiguroida sessiopalvelimia
– ei tarvitse hallita session-vanhenemista
– ei ole riippuvuutta palvelimen muistista
Tämä oli historiallisesti suuri etu.
Seuraukset kehitykselle
Session-less-arkkitehtuuri vaikuttaa suoraan siihen, miten WordPress-lisäosia ja teemoja pitää suunnitella.
1. Ei luonnollista tilanhallintaa
Koska sessioita ei ole:
– lomaketilat pitää tallentaa tietokantaan
– ostoskorit tallennetaan evästeisiin tai meta-tauluihin
– monivaiheiset prosessit vaativat erillisen tilanhallinnan
Tämä tekee esimerkiksi verkkokauppojen arkkitehtuurista monimutkaisemman.
2. Evästeiden suuri rooli
Autentikointi, nonce-tokenit ja monet lisäosien tilat perustuvat evästeisiin. Tämä tarkoittaa:
– riippuvuutta selaimen tilasta
– mahdollisia konflikteja cache-järjestelmien kanssa
– monimutkaisempaa turvallisuuslogiikkaa
3. Lisää tietokantakuormaa
Koska sessiota ei ole muistissa:
– käyttäjän tila haetaan tietokannasta lähes jokaisella pyynnöllä
– usermeta ja options-taulut kuormittuvat
– object cache muuttuu tärkeäksi suorituskyvyn kannalta
Välimuistin ja session-less-mallin suhde
Session-less-arkkitehtuuri sopii erinomaisesti välimuistiin:
– staattinen sisältö voidaan cachettaa helposti
– CDN:t voivat palvella sivuja ilman serverilogiikkaa
– edge-caching toimii tehokkaasti
Ongelmat alkavat, kun:
– sivu sisältää käyttäjäkohtaista dataa
– evästeet estävät cache-osumat
– lisäosat lisäävät dynaamista sisältöä joka pyyntöön
Tällöin cache-hyöty katoaa.
Turvallisuusvaikutukset
Session-less-malli tuo sekä etuja että riskejä.
Edut
– vähemmän serveripuolen session-hijacking -riskejä
– ei muistissa olevia sessioita, joita voi varastaa
– yksinkertainen autentikointimalli
Riskit
– evästeiden varastaminen tarkoittaa suoraa pääsyä käyttäjätilaan
– nonce-tokenien väärinkäyttö voi johtaa CSRF-hyökkäyksiin
– lisäosien oma sessiologiiikka voi olla turvatonta
Lisäosat ja “valesessiot”
Monet lisäosat yrittävät ratkaista session-puutetta:
– tallentamalla tilan usermetaan
– käyttämällä transientteja
– ottamalla käyttöön PHP-sessiot
Tämä voi johtaa:
– yhteensopivuusongelmiin
– cache-konflikteihin
– race condition -tilanteisiin
Kun yksi lisäosa käyttää PHP-sessioita ja toinen ei, syntyy helposti arkkitehtoninen sekasotku.
Large-scale -ympäristöt
Suurissa ympäristöissä session-less-malli on etu:
– ei tarvita keskitettyä session storea
– pyyntö voidaan ohjata mille tahansa palvelimelle
– edge-caching toimii tehokkaasti
Mutta samalla:
– object cache on lähes pakollinen
– tietokantakuorma kasvaa
– käyttäjäkohtainen sisältö on vaikeampi optimoida
Yhteenveto
WordPressin session-less-arkkitehtuuri on historiallinen mutta edelleen relevantti suunnitteluratkaisu. Se tekee järjestelmästä:
– helposti skaalautuvan
– yksinkertaisen hostata
– välimuistiystävällisen
Samalla se aiheuttaa:
– lisätyötä tilanhallinnassa
– suurempaa tietokantakuormaa
– riippuvuutta evästeistä ja tokeneista
Session-less-malli ei ole parempi tai huonompi kuin perinteinen sessioarkkitehtuuri. Se on kompromissi, joka sopii erityisen hyvin sisältöpohjaisiin sivustoihin, mutta vaatii tarkkaa suunnittelua monimutkaisissa sovelluslogiikoissa, kuten verkkokaupoissa tai reaaliaikaisissa palveluissa.
