Isn’t the login username verification usually posted to the server together?
The get method will expose the parameters at the end of the link, but the browser itself does not have any encryption. If it is encrypted, you need to adjust it yourself.
For some form values, whether they are valid and non-empty, etc., there should be a prompt before submission to improve the user experience.
Everything needs to be done. The front-end is for user experience (knowing the problem before making a request), and the back-end is for security.
For enterprise-level services, use https instead of plain text.
Assume that the username must be more than 3 digits; the password must be 6~32 digits; the verification code must be 4 digits; 1. When clicking to log in, it is detected that the username length is greater than 3, the password length is 6~32, and the verification code length is 4; by going to Go down, the alert is not passed; 2. Organize the parameters; post to the server, name pwd code 3, the server receives the parameters 4. Verify whether the length is equal to 4, not equal to 4, the return verification code length is abnormal 5. From the session Get the code, is it consistent with the parameter code, inconsistent return error 6. Check the user name length, password length, incorrect return error 7. If you need to encrypt pwd 8. Select name=name, pwd=pwd from the database , if yes, return user, if not return 0
GET directly displays the data in the URL; POST is "hidden and stolen", the URL cannot be seen, but it can be seen using the browser developer tools; No matter which of the above, "hackers" can capture packets and You can get the plaintext data during data transmission; you can even tamper with/hijack the content and then pass it to the server, or you can directly pretend to be the server and return you false information. If you use HTTPS, the data will be encrypted first during transmission, which is relatively safe. As for parameter verification, it must be done on both the front and back ends, because the JS verification on the front end can easily be bypassed.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Isn’t the login username verification usually posted to the server together?
The get method will expose the parameters at the end of the link, but the browser itself does not have any encryption. If it is encrypted, you need to adjust it yourself.
For some form values, whether they are valid and non-empty, etc., there should be a prompt before submission to improve the user experience.
Everything needs to be done. The front-end is for user experience (knowing the problem before making a request), and the back-end is for security.
For enterprise-level services, use https instead of plain text.
Assume that the username must be more than 3 digits; the password must be 6~32 digits; the verification code must be 4 digits;
1. When clicking to log in, it is detected that the username length is greater than 3, the password length is 6~32, and the verification code length is 4; by going to Go down, the alert is not passed;
2. Organize the parameters; post to the server, name pwd code
3, the server receives the parameters
4. Verify whether the length is equal to 4, not equal to 4, the return verification code length is abnormal
5. From the session Get the code, is it consistent with the parameter code, inconsistent return error
6. Check the user name length, password length, incorrect return error
7. If you need to encrypt pwd
8. Select name=name, pwd=pwd from the database , if yes, return user, if not return 0
GET directly displays the data in the URL;
POST is "hidden and stolen", the URL cannot be seen, but it can be seen using the browser developer tools;
No matter which of the above, "hackers" can capture packets and You can get the plaintext data during data transmission; you can even tamper with/hijack the content and then pass it to the server, or you can directly pretend to be the server and return you false information.
If you use HTTPS, the data will be encrypted first during transmission, which is relatively safe.
As for parameter verification, it must be done on both the front and back ends, because the JS verification on the front end can easily be bypassed.
Get will be exposed, but post will not. Be safe