Static server

The source code

Dynamic server

The source code

Determine static and dynamic servers (also known as static and dynamic pages) to see if the database is requested. If there is no request database, it is a static server; The database in the request is the dynamic server.

In actual combat

/db/users.json as database

structure

[{"id":1."name":"river"."password":"xxx"},
 	{"id":2."name":"lyn"."password":"yyy"}]Copy the code

Read users data

ToString () is followed by json.parse () (deserialization) to get the array

Storing Users data

Json.stringify () (serialized) gets the string, and then writes the data

The first step is to implement user registration

function

The user submits the username and password, and a new line of data is added to the users.json file

Train of thought

The front end writes a form, lets the user fill in name and password, listens to submit event, sends POST request, the data is located in the request body.

The backend accepts the POST request, obtains the name and password in the request body, and stores the data.

Step 2 Implement the user login function

function

Home page home.html, users who have logged in can see their own user name

The login page sign_in.html for submitting the user name and password

If the entered user name and password match, the home page is automatically redirected

Train of thought

The front end writes a form, lets the user fill in name and password, listens to submit event, sends POST request, the data is located in the request body.

The backend accepts the POST request, obtains the name and password in the request body, and reads the data to see if there is a matching name and password. If there is a match, the backend should mark that the user is logged in.

Step 3 mark the user as logged in

Cookie

define

A Cookie is a string sent from the server to the browser, which must save the Cookie (unless deleted by the user) and attach the Cookie to subsequent requests for the same secondary domain name (any request).

The Set – Cookie response headers

MDN

Step 4 Display the user name

Get user information before rendering home.html

If there is a user, replace {{user.name}} with user.name

If there is no user, the login button is displayed

Step 5 Tamper with user_id

Idea 1: encryption

The user_id is encrypted and sent to the front end, which decrypts it when the back end reads the user_id

This works, but there is a security loophole that means the encrypted content can be used indefinitely. Solution: JWT.

Idea 2: Hide information on the server

Put the user information in the server’s session, and then give it a random ID, and send that random ID to the browser

The backend obtains user information through session[ID] the next time it reads the ID

Session is a file, so you can’t use memory, because memory will be empty if the power goes off

Why can’t the user tamper with the ID?

Because id is long and random.

Step 6 Log Out

Train of thought

Delete the session ID from the session

Delete the cookie from the browser (optional)

implementation

The front end makes the logout button, listens for the logout button event, and sends the DELETE Session request

The back end accepts the DELETE Session request, gets the current session ID, deletes it, and issues an expired Cookie with the same name (because it was not deleted)

Step 7 Prevent password leakage

Don’t store plaintext

After getting the plaintext, bcrypt.js encrypts the ciphertext and saves the ciphertext to user.json

When a user logs in, check whether the ciphertext after encryption is consistent. If the ciphertext is consistent, the user knows the password and can log in

Don’t use MD5

MD5 isn’t even an encryption algorithm, it’s a hash algorithm

Further reading