1. props Parent component passes value to child component Child component binds parent component properties Child component internal declaration Use
2 .$emit/$onChild component passes value to parent component (through event form) Child component binds parent component method Child component triggers parent component
3.vuex Global value passing can be used in components of the same level
4.EventBus can be used in components of the same level
4.URL parameters will be stored in the url for use in the next page when the route jumps
5. $attrs/$listeners
6.$parent / $children
localStorage
: H5’s new local storage API can be understood as the browser’s local database, with a size of only 5M. The
corresponding CRUD method:
- setItem corresponds to adding and modifying;
- getItem, key is equivalent to search;
- removeItem, clear is equivalent to delete;
Life cycle: permanently effective
The data stored by vuex is responsive. But it will not be saved, and it will return to the initial state after refreshing. The specific method should be to copy the data and save it in localStorage when the data in vuex changes. After refreshing, if there is saved data in localStorage, take it out and replace the state in the store.
sessionStorage
The life cycle is the current window or tab page. Once the window or tab page is permanently closed, all data stored in sessionStorage will be cleared. But refresh won't.
SessionStorage and LocalStorage are two data storage mechanisms provided by the browser. The main difference between the two is that the life cycle is different
Token and session cookie
Session
session Literally speaking, it is a session.
Because HTTP requests are stateless, the solution I came up with is to send everyone a session ID. To put it bluntly, it is a random string, and everyone receives it differently. sessionid will be saved and transmitted through cookie
Token
password, token
Using Token-based authentication methods, there is no need to store user login records on the server side. The approximate process is as follows:
1. The client uses the username and password to request login
2. The server receives the request to verify the username and password
3. After the verification is passed, the program returns a signed token to the client.
4. The client stores the token, such as putting it in a cookie or Local Storage, and it is used every time to send a request.
5. The server verifies the token and returns the data.
Cookie
The cookie is generated by the server and sent to the browser. The browser saves the cookie in a text file in a certain directory in the form of kv. The next time the same website is requested, the cookie will be sent to the server.
Since the cookie exists on the client, the browser adds some restrictions to ensure that the cookie will not be used maliciously and will not occupy too much disk space, so the number of cookies for each domain is limited.
The user requests to log in -> the server authenticates and sends it to the browser by issuing a cookie containing the sessionID, and at the same time saves the session session -> the browser receives the cookie and saves it locally -> the information in the cookie is sent to the server when logging in to the same domain name next time
This article is very well written, it is very helpful for understanding
cookie-based authentication
A cookie is a simple file originating from a site and stored on a client's computer by the browser. They usually contain a name and a value that identify the client as a specific user with specific permissions to the site.
The way the cookie is linked to the source domain ensures that only the source domain can access the information stored in it. Third-party servers can neither read nor change the content of cookies for this domain on the user's computer.
Former Netscape employees invented cookies in 1993.
Cookie-based authentication is stateful, which means that authentication or session information must be stored on both the client and the server. This information server is generally recorded in the database, and the front end will be saved in the cookie.
The general flow of verification is as follows:
The user enters the login credentials;
the server verifies whether the credentials are correct, creates a session, and then stores the session data in the database;
the cookie with the session id is placed in the user's browser;
in subsequent requests, the server will verify the session id against the database, If the authentication is passed, continue processing;
once the user logs out, both the server and the client destroy the session at the same time.
token-based authentication
With the popularity of single-page applications, and the rise of Web API and the Internet of Things, token-based identity mechanisms are increasingly widely used.
When discussing token-based authentication, it is common to talk about JSON Web Tokens (JWT). Although there are many different ways to implement token, JWT has become the de facto standard, so JWT and token will be mixed later.
Token-based authentication is stateless. The server does not keep track of which users have logged in or which JWTs have been issued. Every request to the server needs to carry a token that authenticates the request. This tag can be added in the header, sent in the body of the POST request, or sent as a query parameter.
The workflow is as follows:
The user enters the login credentials;
the server verifies whether the credentials are correct, and then returns a signed token;
the client is responsible for storing the token, which can be stored in local storage or a cookie;
the request to the server brings this token;
the server decodes the JWT, if If the token is valid, the request is processed;
once the user logs out, the client destroys the token.
Advantages of token over cookie:
- Support cross-domain access
- no status
- Anti-cross-site request forgery (CSRF)
- multi-site use
- Support mobile platform
- performance
- JWT
Summary:
The session is stored in the server, understood as a state list, has a unique identification symbol sessionId, and is stored in the cookie. After receiving the cookie, the server parses out the sessionId, and then searches in the session list to find the corresponding session. Relying on cookie
A cookie is like a token, loaded with sessionId, stored on the client, and the browser usually adds it automatically.
The token is also similar to a token, stateless, user information is encrypted into the token, and the server can know which user it is after decrypting it after receiving the token. It needs to be added manually by the developer.
For reasons such as cross-domain requests and server resource overhead, Token came into being.
Token-based authentication is stateless, and we do not store user information in the server or session.
NoSession means that your program can increase or decrease the machine as needed without worrying about whether the user is logged in or not. Just verify the token every time a request is received.
Available libraries:
js-cookie
View cookies directly in the browser:
document.cookie.split("; ");
