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äonlinellään itsenäisesti, ja käyttäjän tila määritellään evästeiden, tietokannan ja tokenien avulla.
Session-less tarkoittaa sitä, että:...
WordPress syntyi aikana, jolloin:...
Session-less-arkkitehtuuri vaikuttaa suoraan siihen, miten WordPress-lisäosia ja teemoja pitää suunnitella....
Session-less-arkkitehtuuri sopii erinomaisesti välimuistiin:...
Session-less-malli tuo sekä etuja että riskejä....
Monet lisäosat yrittävät ratkaista session-puutetta:...
Suurissa ympäristöissä session-less-malli on etu:...
WordPressin session-less-arkkitehtuuri on historiallinen mutta edelleen relevantti suunnitteluratkaisu. Se tekee järjestelmästä:...
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äonlinellä 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.
