Attualmente sto valutando l'ottimizzazione delle prestazioni e sto prendendo in considerazione un modo per accelerare la gestione delle sessioni basata sui cookie. Ci sono vantaggi nell'avere un identificativo di sessione in atto quando non ci sono dati sul lato del server a cui fa riferimento. Sto cercando di capire se è una buona idea collegare un indicatore all'ID di sessione che mostra se ci sono dati server. Ciò eviterebbe la necessità di tentare di recuperare dati inesistenti in alcuni casi e potrebbe essere ulteriormente esteso per altri semplici casi (e, g, per distinguere tra diversi back-end di memorizzazione dei dati di sessione lato server).
es. la prima volta che un utente raggiunge un sito, ottiene un ID di sessione "abc" e ...
Set-Cookie: sessionid=0abc; HttpOnly
Quando vengono aggiunti dati alla sessione ....
Set-cookie: sessionid=1abc; HttpOnly
Ovviamente la presenza / assenza di dati sul lato server sarà evidente ad un intercettatore. E c'è la possibilità che il cookie venga manomesso in modo tale che appare sia associato ai dati serveride - ma in questo caso la cosa peggiore che accada è che si comporta allo stesso modo delle sessioni attualmente .
Sono anche consapevole che nell'UE dobbiamo ora chiedere agli utenti il consenso prima di eliminare tutti i cookie non critici.
Inoltre, non sto proponendo di usare 3 identificativi di sessione di lettere! A parte un piccolo stub, il resto dell'ID di sessione continuerebbe a seguire le consuete pratiche di dati essenzialmente casuali. Suppongo che non ci sia alcun guadagno da fare se lo registri nel punto in cui lo stub cambia.
Ma qualcuno può vedere un problema che non ho?