Actual combat: Chapter 1: Preventing others from accessing users’ private data through their urls

Solution: Prevent other users from accessing the user’s private data through the USER’s URL. Idea 1: Add a userId to the URL and check whether the user can access the user’s private data according to the usrId in the URL and the userId saved in the session. In this case, the userId will be exposed in the URL. Solution: URL make general, data requests need to be triggered by the user (Baidu) (not recommended) Login operations are required for access. A userId is added to the session and a userId is added to the record. Each access is based on the record ID in the URL and whether the userId in the data matches the userId in the session. However, this will result in the need to query the database before the results are known, solution: Redis does user authentication for the database. When a user accesses the request address of an order, he/she carries a token. JWT adds a timestamp to the token and puts the token in the header of each request. After receiving the token, he/she checks whether it is the user’s own account. (This requires the front end to put the token on when the user clicks to send a request.) Idea 4: Perform authorization and authentication at the background system level. So although the URL is the same, only the user who has logged in and been authorized can show him the specified data. Idea 5: Add a middleware to the routing place and route all the routes to be verified through this middleware. A long hash code is generated each time a user logs in (ensuring that each user does not repeat the hash code). Just validate the hash every time you request it. Every login is different and impure is leaking problems. 6. Compare the browser’s Cookie with the user ID in the cache. Each interface has a custom annotation, which sets the first login to save the user ID. The request is sent to the background interface to directly obtain the user ID from the cache. Other parameters in the request can be associated with the query of the corresponding table to obtain the user ID. (Some interface parameter lists have member_id, which is the id of the user after logging in. This interface is retrieved directly from the cache.)