[OT] Gestione sessione applicazioni Web lato server o lato client?

[fermat]

ciao!

vorrei fare una domanda generica da un dubbio che mi è sorto l'altro giorno parlando con alcuni sviluppatori web.
domanda generica, senza andare a guardare i linguaggi usati.

---
in genere, quando crea un'applicazione web, sono solito salvare in variabili di sessione alcune informazioni che possono servire all'utente in varie parti del programma.
lo faccio usando "il lato server" (per intenderci, $_SESSION['QUALCOSA'] se parliamo di php).
quindi, ad esempio, l'utente fa il login e salvo in sessione il suo username (visibile in tutte le pagine), il suo id (utile per recuperare i dati dal db), ecc.

---
ieri, stavo appunto parlando con questi tizi, che mi hanno detto questo.
loro salvano tutti questi dati lato client (localStorage/sessionStorage/quello che volete) senza usare le sessioni lato server.
questo perchè adottano un'architettura tutta basata su AJAX.
quindi la parte server (php ad esempio) la usano solo come servizio rest.
per fare un esempio pratico, hanno il form che invia dati tramite ajax a php.
php risponde OK/KO.
se risponde OK, rimanda alla chiamata ajax anche lo username e l'id dell'utente.
salvano questi dati in sessionStorage, e li usano poi nelle pagine.

---
non so se è una moda, o sono io che sono rimasto indietro.
e di per se non ho nulla in contrario, ma qualche dubbio mi viene.
ad esempio la sicurezza.
oppure, il non uso di alcun framework come react.
uno ha scritto tutto il codice in funzioni js, usando jquery per le chiamate ajax.
anche qui, la sicurezza?
e poi, non c'è codice javascript a dismisura cosi facendo?

voi che dite sulla questione?
giusto per capire un attimo, perechè mi sembravano molto convinti.

[MItaly]

In genere in un'architettura di questo genere c'è una prima chiamata per autenticarsi; il server rilascia un token di qualche tipo (che rimane l'unica informazione "di sessione" persistente per un po' che sta lato server), che il lato client si salva a livello JavaScript. Tutte le chiamate ad API ricevono il token, che usano per sapere se l'utente è effettivamente autenticato e se è autorizzato a fare quello che la funzione richiede. Tutto il resto dello stato è lato client, il server rimane solo come provider di servizi.

[fermat]

In genere in un'architettura di questo genere c'è una prima chiamata per autenticarsi; il server rilascia un token di qualche tipo (che rimane l'unica informazione "di sessione" persistente per un po' che sta lato server), che il lato client si salva a livello JavaScript. Tutte le chiamate ad API ricevono il token, che usano per sapere se l'utente è effettivamente autenticato e se è autorizzato a fare quello che la funzione richiede. Tutto il resto dello stato è lato client, il server rimane solo come provider di servizi.

si, immaginavo.
ed infatti è una domanda che ho fatto (mi ero dimenticato di scriverlo).

non si è parlato di token di nessun tipo.
e l'autenticazione è fatta con username/password da form.
solo che il form non viene indirizzato ad uno script lato server, ma viene fatta una chiamata ajax.
tramite ajax vengono inviate le coppie username/password.

uno ci ha costruito un intero ecommerce con questa architettura.

[alka]

tramite ajax vengono inviate le coppie username/password.

Probabilmente viene usata una Basic Authentication o qualcosa di simile.

uno ci ha costruito un intero ecommerce con questa architettura.

Questa è l'impostazione favorita per lo sviluppo moderno di applicazioni Web, per tutta una serie di motivi (risparmio di banda, semplificazione del backend, maggiore fruizione della UI lato utente, migliori performance, sfruttamento delle risorse del dispositivo, apertura automatica a più client di diverso tipo, ecc.).

Che poi lo si faccia aiutandosi o meno con un framework completo che gestisce tutto, o una libreria (come React di cui agevolo mia guida in costruzione), è una scelta personale.

Ciao!

[MItaly]

Il token è semplicemente una convenienza per non fare passare di continuo utente e password "sul filo", specie perché se l'autenticazione è fatta bene dovrebbe essere un challenge-response di qualche tipo e che quindi richiede più richieste e un minimo di stato (il server manda un nonce, il client manda hash(hash(password) + nonce), il server verifica se è coerente con quello che sa e restituisce un token valido in questo caso). Se non ci si pone il problema di mandare in giro di continuo le credenziali ci si può riautenticare ad ogni richiesta, senza che questo sia per l'applicazione in sé un problema di sicurezza.

[fermat]

ok in sostanza l'iter potrebbe essere una cosa del genere:
- dal form invio le credenziali
- lato server controllo che le credenziali siano valide (magari faccio il solito hash della password da confontare con l'hash sul db), ed assegno un token all'utente
- per tutte le prossime richieste, controllo che il token sia valido, e nel caso eseguo le operazioni richieste
- eventuali dati utili per tutte le pagine (banalmente lo username) li salvo lato client, in modo da non doverli richiedere continuamente al server