1. Component basis
Single-file components (aka ".vue" files), which allow Vue component templates (<template></template>), logic (<script></script>), styles (<style></style> ) encapsulated in a single file
2. Load the component (introduced in App.vue because it is the root component)
Step 1: Introduce the component import MyComponentVue form './components/MyComponent.vue'
Step 2: Mount component components: {MyComponentVue}
Step 3: Display component <my-componentVue/>
3. IWT instead of Session (session)
- Session usage
We know that HTTP is stateless, so if you want to implement the function of "users can only access certain resources after logging in", developers must simulate the state preservation based on HTTP. The classic way to realize the user login function is to use Session, that is, after the user login verification is successful, the server generates a unique identifier SessionId, and the server not only returns the SessionId to the browser, but also the corresponding relationship between the SessionId and the login user information Save it in the server memory; when the browser sends a request to the server again, the browser will carry the sessionId in the HTTP request, and the server can get the user's information from the server's memory according to the SessionId, thus realizing User login function.
We generally save the SessionId in the Cookie, and the Session data is saved in the server memory by default. For a distributed cluster environment, it is not appropriate to store the Session number in the server memory. It should be saved in a shared one for all cluster instances to access. on the state server. ASPNET Core Session mechanism, and we also use Redis, Memcached, relational database, etc. as state servers to support distributed cluster environments.
Session is a classic solution to save client-related state on the server side in web development, but in a distributed environment, especially in the era of "separation of front-end and back-end, multi-client", Session exposes many shortcomings. These disadvantages include but are not limited to the following points.
The first point. If the session data is saved in memory, when the number of logged-in users is large, the session data will occupy a lot of memory, and it cannot support a distributed cluster environment.
The second point is that if the Session data is saved to a state server such as Redis, it can support a distributed cluster environment, but
Every time a client request is encountered, the session data must be obtained from the state server, which will slow down the response speed of the request. Especially for some distributed environments across multiple data centers, state transfer across data centers is even more difficult. So next we introduce the concept and usage of JWT .
- The concept and usage of JWT
In current project development, we tend to use JWT instead of Session for login. The full name of JWT is JSON web token. As can be seen from the name, JWT uses JSON format to store token information. The JWT mechanism does not save the user's login information on the server side, but saves the login information (also called a token) on the client side . In order to prevent data falsification on the client side, the token stored on the client side has been signed, and the signature key is known only to the server side. Every time the server side receives the token submitted by the client side, it must check the signature. If If it is found that the data has been tampered with, it refuses to accept the token submitted by the client.
Structure diagram of JWT
The header of the JWT saves the description of the encryption algorithm, the payload saves information such as user ID, user name, and role, and the signature is a value calculated based on the header and the payload.
The process of JWT login is as follows.
The client sends a user name, password, etc. request to the server to log in.
The server verifies the user name and password, and if the verification is successful, the user-related information such as the user's ID and role is taken out from the database.
The server uses a key that only the server knows to sign the JSON string of user information to form signed data.
The server side concatenates the JSON string of user information and the signature to form a JWT, and then sends it to the client.
The client saves the JWT returned by the server, and brings this JWT every time the client sends a request to the server.
Every time the server receives the JWT carried in the browser request, the server uses the key to verify the signature of the JWT. If the verification is successful, the server reads the user's information from the JSON string in the JWT . In this way, the server will know the user corresponding to the request, and the login function will be realized.
3. Advantages of JWT
(1) The state is saved on the client side, not the server side. Naturally suitable for distributed systems.
(2) The signature ensures that the client cannot forge data.
(3) Higher performance, no need to communicate with the central state server, pure memory calculation.