Session storage - GradedJestRisk/web-training GitHub Wiki

All data that should be persisted for a long time, that cannot be lost in-between connection, should be stored on a common storage, "serve-side", usually a database, itself build on top on a file-system on magnetic disk. Replication scheme enable such data to be persisted across several server to prevent data loss, but the idea is there's a single source of truth.

URL enable access to such information (kind of serialized application state). For example, the URL http://who-is-who.com/people/john-doe is self-contained and load a coherent set of data to the user, based on John Doe's information in database.

However, another kind of data should be handled, but is usually not persisted, because of its transient nature.

There's two kind such data in web applications :

  • authentication method data, that should be provided on each request to the server
  • transient user data entry:
    • data that is planned to be sent to the server to be persisted, eg a message in an email application (gmail)
    • data that will be discarded whatever happens, eg a result in imperial/metric conversion app. There's no clear-cut distinction with the former, as even when the user doesn't care, this data can be persisted anyways for marketing purpose
Such transient data is called session data, session being the "thing" the user does during a connexion to the application.

Session data can be stored:

  • server-side: in-memory or in filesystem (database)
  • user-side: in-memory or in filesystem
User-side memory, when a SPA application, can be done by the application itself. However, keep in mind that nothing prevent the user (or the machine) to reload the application (eg. by hitting F5 key), which is freeing the application memory space, thus losing data

User-side filesystem "in-browser" readily available options are:

  • cookies (stored in single files)
  • storage, available as :
    • session, available for the session lifespan, cleared upon browser closure
    • local, available till cleared by the user or browser removal from OS
Local storage can be used when you want the user to connect once, and not to connect again after each browser/OS shutdown. Example is Pix token, stored as a JWT 
ember_simple_auth-session:"{
  "authenticated":{
   "authenticator": "authenticator:oauth2",
   "token_type": "bearer",
   "access_token": "eyJhbGciOiJI(..)vlKMlOFy5NqKK63xRo",
   "user_id": 670450
  }
}"

It does not imply such authentication will be guaranteed life-long: the storage is, but the token itself has a lifespan and, while remaining in the storage, will become useless after expiration.

Browser local storage is not shared across browsers (eg. Firefox and Chrome), but is between browser instances.

⚠️ **GitHub.com Fallback** ⚠️