Keskustelu: Nettisivujen teko: Sessioiden / evästeiden sisältö

1. Kannattaako mieluummin laittaa yhteen sessioon yhdistämällä kaksi tietoa käyttäjästä, vaiko käyttää kahta eri sessiota? $tieto1."|".$tieto2 tuntuu niin purkkaviritelmältä, mutta toisaalta noita sessiotiedostoja syntyisi kaksi kertaa enemmän jälkimmäistä metodia käyttäen. Jos käyttäjiä on yhtä aikaa sisällä suurempia määriä (vaekka 100-1000) niin kumpaa suosittelisitte? Kokemusta?

2. Mitä tietoja yleensäkin kannattaa sessioissa säilyttää? Tällä hetkellä pidän niissä merkkiä kirjautuneisuudesta. Entäpä evästeissä? Ei mitään arkaluontoista, mutta ei myöskään mitään helposti itse asetettavaa?

Kaikki istuntoon kuuluvat muuttujat menevät samaan tiedostoon.

<?php
session_start();
$_SESSION['eka'] = "Ensimmäinen";
$_SESSION['toka'] = "Toinen";
?>

Edellisen koodinpätkän tuloksena on tällainen tiedosto:

eka|s:11:"Ensimmäinen";toka|s:6:"Toinen";

Ei siis ole tarpeen tunkea kaikkea tietoa samaan muuttujaan, vaan muuttujia voi ihan hyvin olla enemmänkin.

Istunnot ovat siinä mielessä evästeitä parempia, että käyttäjä ei pääse näkemään tai muokkaamaan tietoja, vaan näkee evästeessä ainoastaan istunnon tunnuksen. Toisen käyttäjän istunnon tunnuksen arvaaminen on aika mahdoton tehtävä.

Hmm.. Ei tullut mieleenkään kokeilla moista, jotenkin automaagisesti mietin, että niistä tulee kaksi tiedostoa ;__;. Session kaappauskin on mahdollista esim. phpsessid:n avulla, johon auttaa sen piilottaminen keksiin (hankalampi tehdä vieraalla palvelimella kun ei pääse asetuksia sörkkimään), käyttäjän ip:n tallentaminen sessioon ja sessioid:n regenerointi jokaisella sivulatauksella.

Jos tahdon tietyn sivun olevan mahdollista käyttää vain pääsivun kautta, toimiiko seuraava: Laitan pääsivulle globaalin $_safetyvar = true; ja tarkistan sillä tietyllä sivulla onko sitä asetettu? Register_globals on tietääkseni off, mutta senkin riskin voisi hoitaa tarkistamalla, tuliko tuo muuttuja requestilla vai ei ja käyttämällä strictiä vertailua.

EDIT: Alla tulikin hyvä ratkaisu, kiitos siitä.

tsuriga kirjoitti:

Jos tahdon tietyn sivun olevan mahdollista käyttää vain pääsivun kautta, toimiiko seuraava: Laitan pääsivulle globaalin $_safetyvar = true; ja tarkistan sillä tietyllä sivulla onko sitä asetettu? Register_globals on tietääkseni off, mutta senkin riskin voisi hoitaa tarkistamalla, tuliko tuo muuttuja requestilla vai ei ja käyttämällä strictiä vertailua.

Käytä constantteja, niin ei tarvitse tuommosia miettiä.

Tai sitten voisin käyttää taulukkoa ja sen jotain indeksiä. Ja seuraava kysymys:

Ajattelin tässä tehdä oman sessiohandlerin.
1) Kun muodostetaan sessioid:tä, olisiko järkeä tehdä siitä ajasta ja random-kirjaimista muodostettu hashi? Turvallisuusseikkoja.
2) Onko sessioiden kryptaamisesta suurikin hyöty? Koska jos sessiotiedostoihin pääsee jotenkin käsiksi, niin eikö voisi myös olettaa, että hyökkääjä pystyisi muokkaamaan php-tiedostoja haluamallaan tavalla?

Jos jaksamusta löytyy niin saa toki esittää kannanottoja seuraavan sivun kohdan security alla esitettyihin ominaisuuksiin: http://www.code.dearneighbor.com/db_esession.html

1. Funktio uniqid on tarkoitettu varta vasten id-numeron muodostamiseen. Kellonaika (sekunnin tarkkuudella) id-numeron taustalla on siinä mielessä huono, että sen voi arvata.

2. En minä ainakaan tekisi moista. Istuntoihin liittyvät tiedostot ovat tietyssä hakemistossa palvelimella.

Mureakuhassa on myös aiheeseen liittyvä artikkeli: http://mureakuha.com/artikkelit/14

1. Figures.
2. Juu en minäkään taida. Ellei niissä säilytä jotain arkaluontoista niin tuskinpa se on kannattavaa.

Entäs onko mahdollista tehdä muuttaa tuota id:n laskualgoritmia, muuten kuin php.inistä vääntämälllä? Omassa session handlerissa voisi tietysti write-metodissa $id:tä vielä muuttaa, vaan mitenkäs tätä sitten luettaisiin read-metodissa?

Bump. Huomasin tuossa, notta uloskirjautuminen ei enää toiminut kun vaihdoin session nimen session_name-funktiolla. Ihan näin ilmoitusluontoisesti.