Details of client Session in ES0en. js programming

Static websites are easy to expand. You just need all the cache, and you don't have to think about combining stateful content from different servers to the user.

Unfortunately, most Web applications use stateful content to provide a personalized experience. If your app can log in, remember the user's Session. The classic approach is for the client to set up Cookie containing random Cookie identifiers with only 1Session, and the identified Session data to be saved to the server.

Extend stateful services

When extending your services, you definitely have three options:

The different servers synchronize Session data Different servers connect to single point center (get Session) Ensure user access to the same server

But both have flaws:

Synchronizing data adds performance overhead Single point center reduces system scalability What if the server the user last accessed needed maintenance

However, if you think about it another way, there is a fourth option: keep the Session data on the client side

The client Session

Saving Session on the client has one advantage:

It doesn't matter which server, the Session data is valid There is no need to maintain server state Server synchronization is not required Add any new server

But client Session has a serious problem: you can't guarantee that users won't tamper with Session data.

For example, you save the user's ID in Cookie. Users can easily modify it to access someone else's account.

This seems to negate the possibility of client Session, but there is a clever way to solve the problem: encrypt the Session data (still in Cookie). There is no need to worry about the user modifying the Session data, the server will verify the data.

In practice, it is Cookie to save 1 encrypted Server Key. Server Key has the right to read and modify Session data only after verification. This is the client Session.

Node client Session

Node. JS has a library that can implement client Session: node-ES63en-ES64en. It can replace the built-in session and cookieParser middleware of Connect (1 Node middleware framework).

Application of Express Framework:

const clientSessions = require("client-sessions"); 

app.use(clientSessions({ secret: '0GBlJZ9EKBt2Zbi2flRPvztczCewBxXK' //  Set up the 1 A random long string ! })

Then, add attributes to the req.session object:

app.get('/login', function (req, res){ req.session.username = 'JohnDoe'; });

Read properties:

app.get('/', function (req, res){ res.send('Welcome ' + req.session.username); });

Terminate Session using the reset method:

app.get('/logout', function (req, res) { req.session.reset(); });

Immediately cancel Persona Session

(Note: Persona is the network identity system launched by Mozzilla)

Unlike server-side Session, the problem with client-side Session is that the server cannot remove Session.

On the server side, you can delete the Session data. The Session identified by any client Cookie probably does not exist. However, when the client is architected, Session data is not on the server, and there is no guarantee that Session data will be deleted on each client. In other words, we cannot synchronize the client state of the user (logged in) and the server state (logged out).

To remedy this, expiration time was added to client Session. Validate expiration time before expanding Session data (encrypted and packaged). If it expires, the Session data is discarded and the user state is changed (such as logout).

The expiration mechanism works well in many applications (especially short expiration time requirements). As in Persona, when a user notices that their password is threatened or corrupted, we need to provide a way for the user to log out of Session data immediately.

This means that 1 bit of status information needs to be kept at the back end of the service. The way we handle instant logout is to add 1 Token to the user data table and Session data.

Each API call compares Token in Session data to Token in the database. If not, return an error message and exit the user.

This adds extra database operations to query Token. Fortunately, most OF the API calls require reading the user data table, so just take Token1 with you.