Home > Web Front-end > JS Tutorial > Detailed explanation of the use of client Session in Node.js programming_node.js

Detailed explanation of the use of client Session in Node.js programming_node.js

WBOY
Release: 2016-05-16 15:53:22
Original
1152 people have browsed it

Static websites are easily scalable. You just cache it all and don't need 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 application can log in, it needs to remember the user's Session. The classic processing method is that the client sets a cookie containing a random unique Session identifier, and the identified Session data is saved to the server.


Extending stateful services

When expanding your service, you definitely have three options:

  1. Synchronize Session data between different servers
  2. Different servers connect to a single point center (obtain Session)
  3. Ensure users access the same server

But they all have flaws:

  • Synchronizing data increases performance overhead
  • Single point center reduces system scalability
  • What to do if the server the user visited last time needs maintenance

However, if you think about it from another angle, you will find a fourth option: save Session data on the client


Client Session

Saving Session on the client has some advantages:

  • It doesn’t matter which server, the session data is valid
  • No need to maintain server status
  • No server synchronization required
  • Add a new server at will

But there is a serious problem with client-side Session: you cannot guarantee that users will not tamper with Session data.


For example, you save the user's ID in a cookie. It can be easily modified by users to gain access to other people's accounts.

This seems to negate the possibility of client-side Session, but there is a way to solve this problem neatly: encrypt and package the Session data (still stored in Cookie). In this way, there is no need to worry about the user modifying the Session data, the server will verify the data.

In practical application, an encrypted Server Key is stored in the cookie. Only after Server Key verification has 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-side Session: node-client-session. It can replace the built-in session and cookieParser middleware of Connect (a Node middleware framework).

Usage in Express framework applications:

const clientSessions = require("client-sessions"); 
Copy after login
app.use(clientSessions({ secret: '0GBlJZ9EKBt2Zbi2flRPvztczCewBxXK' // 设置一个随机长字符串! })
Copy after login

Then, add properties to the req.session object:

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

Read attributes:

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

Use the reset method to terminate the Session:

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

Log out Persona Session immediately

(Note: Persona is an online identity system launched by Mozzilla)

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

In server-side architecture, you can delete Session data. The Session identified by any client cookie may not exist. However, in the client-side architecture, the Session data is not on the server side, and there is no guarantee that the Session data will be deleted on every client. In other words, we cannot synchronize the user's client state (logged in) and server state (logged out).

In order to make up for this defect, an expiration time is added to the client Session. Verify the expiration time before expanding the Session data (encrypted and packaged). If it expires, discard the Session data and change the user status (such as logging out).

The expiration mechanism works well in many applications (especially short expiration time requirements). For example, in Persona, when the user discovers that the password has been threatened or damaged, we need to provide a method for the user to log out of the session data immediately.

This means keeping a little bit of state information in the service backend. The way we handle instant logout is to add a Token in the user data table and Session data.


Each time the API is called, the Token in the Session data is compared with the Token in the database. If not, return an error message and exit the user.

This will add redundant database operations to query the Token. Fortunately, most API calls require reading the user data table, so just bring the Token along with it.


Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template