The use of client session in Node.js programming

This article mainly introduces the use of client session in Node.js programming, is the basic knowledge of node.js learning, need friends can refer to the following

Static Web sites can easily be extended. All you need to do is cache all, and you don't have to consider a stateful content from a different server combination to the user.

Unfortunately, most Web applications use stateful content to provide a personalized experience. If your application can log in, you need to remember the user's session. The classic approach is for the client to set a cookie that contains a random unique session ID, and the identified session data is saved to the server.

Extended stateful Service

When extending the service, you must have three choices:

Synchronizing session data with different server ends

Different service-side Connection Single Point center (get session)

Ensure user access to the same service side

But they all have flaws:

Synchronizing data increases performance overhead

Single Point center reduces system scalability

What if the server on which the user last accessed needs maintenance?

However, if you think about it another way, you'll find a fourth option: Save session data on the client

Client session

There are some advantages to saving sessions on the client:

No matter which server, the session data is valid

No maintenance service-side status required

No server-side sync required

Add any new service side

However, there is a serious problem with client session: You cannot guarantee that the user does not tamper with session data.

For example, you save the user's ID in a cookie. Users can easily modify it to access other people's accounts.

This seems to negate the possibility of a client session, but there is a way to solve the problem cleverly: Encrypt and package session data (or in cookies). This does not need to worry about the user to modify the session data, the server will validate the data.

The actual application is to save an encrypted server Key in the cookie. Server key verifies the right to read and modify session data. This is the client session.

Node Client session

Node.js has a library that can implement client session:node-client-session. It can replace the session and Cookieparser middleware built into connect (a node middleware framework).

Use in the Express Framework application:

?

1const clientsessions = require ("client-sessions");

?

1app.use (Clientsessions ({secret: ' 0gbljz9ekbt2zbi2flrpvztczcewbxxk '//Set a random long string!})

Then, add the properties to the Req.session object:

?

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

Read properties:

?

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

To terminate the session using the Reset method:

?

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

Instant logoff persona session

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

Unlike server-side sessions, the problem with client sessions is that the service side cannot delete the session.

Server-side architecture, you can delete session data. The session of any client cookie identification may not exist. However, the session data is not on the server side of the client schema, and the session data is not guaranteed to be deleted at each client. In other words, we are unable to synchronize the user's client status (logged in) and service-side status (logoff login).

To compensate for this flaw, the expiration time is added to the client session. Validates the expiration time before the session data is expanded (encrypted and packaged). If it expires, discard session data and change user status (such as logout login).

The expiration mechanism works well in many applications (especially when the short expiration time is required). In the case of persona, when the user discovers that the password is threatened or corrupted, we need to provide a way for the user to unregister the session data immediately.

This means that a little bit of state information needs to be preserved on the service backend. The way we deal with instant logoff is to add a token in the User data table and session data.

Each API call is compared to the token in the session data and the token in the database. If it is not the same, return the error message and exit the user.

This will append the extra database operations to query token. Fortunately, most API calls need to read the user data table, and take the token with you.