IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

Explicació

El protocol HTTP és un protocol stateless és a dir no manté cap mena d'informació d'estat o memòria entre peticions. Els protocols que mantenen l'estat poden compartir informació entre diferents peticions. Al temps que transcorre entre la primera petició i l'última petició que estan relacionades i comparteixen informació d'estat l'anomenem sessió. Per això diem que el protocol HTTP és un protocol sense estat.

De totes formes els desenvolupadors web poden utilitzar múltiples estratègies per a poder implementar una sessió amb HTTP:

URL parameters

Normalment mitjançant la part d'una URL anomenada Query String podem passar dades entre una pàgina web i un altre i per tant implementar un sistema de sessió rudimentari. Un exemple, es pot mantenir la informació d'estat o sessió nom del usuari posant a totes les URLS la query string "?username=Sergi":

http://www.myweb.com/index.html?username=Sergi
http://www.myweb.com/contacta.html?username=Sergi
http://www.myweb.com/anotherwebpage.html?username=Sergi

De forma similar també podriem mantenir informació passant dades per POST amb formularis o mecanismes de programació amb Javascript però és un cas força menys aplicable.

Cookies

Les cookies permeten guardar informació bàsica en el client i aquesta informació es compartida amb el servidor web que ha creat la cookie (les cookies es transmeten entre servidor i client mitjançant les capçaleres HTTP, vegeu l'article sobre HTTP Cookies)

Tant els paràmetres URL com les cookies tenen l'inconvenient que les dades són llegibles i modificables (encara pitjor a nivell de seguretat). Per tant no podem compartir dades sensibles per la seva visibilitat ni podem basar la seguretat del sistema en aquestes variables.

La solució és guardar aquesta informació de sessió o estat a la banda del servidor (server side) i identificar-la amb algun tipus identificador com un id numèric o encara millor un hash i aleshores deixem que el client només conegui (via una cookie o un URL parameter) aquest identificador i aleshores ja tenim les sessions implementades.

NOTA: Els identificador no han de ser fàcilment endevinables sinó volem que sigui fàcil segrestar la sessió d'altres usuaris

També es pot utilitzar el client per emmagatzemar la informació però només utilitzant un sistema de xifratge és a dir que les dades estiguin xifrades al client i només el servidor conegui la clau per desxifrar les dades.

NOTA: Tingueu en compte que utilitzar SSL/HTTPS també és important però no suficient ja que permet que les dades no siguin interceptables però el client HTTPs té accés a les dades sense xifrar

Base de dades (estat) al servidor

Es poden implementar múltiples solucions de base de dades per emmagatzemar la sessió al servidor:

  • Fitxer o fitxers: les dades de la sessió es guarden de forma persistent a un fitxer
  • Base de dades relacional: tipus MySQL, sqlite, etc.
  • memcached / redis: Bases de dades en memòria
  • Variables/array: la sessió es guarda a una variable d'estat del codi

Observeu que precisament la implementació de sessió de Laravel suport múltiples drivers ([1]) com també passa amb eines com Code Igniter.

Recursos:

Base de dades (estat) al client

Cookies: com ja hem comentat més amunt és la forma més bàsica d'emmagatzemar dades al client
  • Local Storage: és una funcionalitat de HTML5 que podem utilitzar per emmagatzemar informació de la sessió

A nivell de seguretat és importat tenir en compte que no podem emmagatzemar dades confidencials al client sense utilitzar xifratge. Per exemple Laravel per defecte utilitza xifratge per emmagatzemar dades a les cookies (en canvi la comanda setCookie de PHP emmagatzema en text clar)

Híbrid amb estat al client i al servidor De fet sol ser la solució més habitual que combina:

  • Base de dades al servidor on es guarda l'estat de la sessió
  • Cookie o Local Storage al client on només es guarda un identificador segur de la sessió. Els identificadors solen ser hashes per tal d'impedir Session Hijacking

Recursos

Seguretat

Session Hijacking

Els identificador de sessió han de ser identificador que no és puguin esbrinar. Normalment seran hash o tokens que identifiquen (és a dir són identificador únics a la base de dades) la sessió. Se sol utilitzar una operació tipus (exemple a Laravel):

Hash::make(str_random(10));

és a dir un hash d'un número aleatori prou gran.

Llenguatges de programació

PHP

Amb PHP es pot iniciar una sessió amb la funció session_start(). Per accedir i/o establir el valor de les variables de sessió s'utilitza la variable superglobal

$_SESSION

Vegem un exemple:

<?php
// Start the session
session_start();
?>
<!DOCTYPE html>
<html>
<body>

<?php
// Set session variables
$_SESSION["favcolor"] = "green";
$_SESSION["favanimal"] = "cat";
echo "Session variables are set.";
?>
</body>
</html>

La configuració s'estableix amb variables de configuració (vegeu fitxer php.ini i la comanda phpinfo). Exemples:

PHPSESSID és el nom per defecte que sol tenir la cookie amb l'identificador de sessió de PHP (per seguretat es tracta d'un hash)
Per defecte la sessió se sol guardar utilitzant un driver/handler de fitxers i el path és /var/lib/php/sessions

Recursos:

Laravel

Vegeu Laravel Session


Resources:

APIs REST

Les APIs REST (especialment les RESTFul) per definició i per múltiples avantatges que té es desitja que siguin stateless i per tant no es pot utilitzar la sessió ni variables d'estat compartides entre peticions a la API.

Vegeu també

Enllaços externs