[Determine user logon] is the PHP process correct? Query data inventory cookies every time

[Determine user logon] is the PHP process correct? Every time I query the data inventory COOKIE, I make my own PHP to determine whether the user is logged on:

[Process]
1. First, determine whether there is a cookie ('uid') & cookie ('uid'). If no bounce loop is detected
2. if yes, connect to the database to query the records corresponding to the uid. If no record is changed, the system will jump out of the loop detection and cancel all user cookies.
3. if yes, check the cookie ('upwd ') = md5 ($ rs [pwd]. cookie ('salt'). If not, the system prompts you to change the password and log on again.
4. if the values are equal, the cookie ('email ') = md5 ($ rs [email]) is detected. if the values are not the same, the system prompts that the email address has changed and you need to log on again.
5. if yes, the user is the current logon user.

But!
[Problem]
1. each time you connect to the database, reducing database queries is the key to user optimization. if you go to the database every time, the performance will be affected.
2. the best way is to optimize it. check whether the logon process is correct.

[Another idea]
1. save $ uid, $ uname, and $ lastactive (last response time) to the SESSION.
2. if a session ('uid') & session ('uname') detects time ()-$ lastactive> 3600, connect to the database for query (based on the cookie above ), otherwise, it will be used directly (session storage location php. default position configured by ini)

[Problem]
1 if it is stored in the SESSION, will it be affected in the case of high concurrency?

Reply to discussion (solution)

When using the second solution, you are concerned about high concurrency.
So if we adopt the first solution, will we not consider high concurrency?

In your first solution, users' passwords and emails are stored in cookies, and the data is always running on the internet. do you think it is safe?

The database should be in a broad sense.
Although the speed of file system-based relational databases (SQL) may be slightly inferior, they all provide memory-based memory tables
Besides, the database has another branch: memory-based noSQL
Therefore, the additional overhead of database queries is negligible.

The process for determining whether a user is logged on is:
If the cookie ('uid') does not exist, log on to the system.
Otherwise, query the database and check whether the last logon location of the uid is the same as this one:
Confirm if they are the same
If there are different requests, a prompt will be issued. if there is a conditional transfer, login is required.

When using the second solution, you are concerned about high concurrency.
So if we adopt the first solution, will we not consider high concurrency?

In your first solution, users' passwords and emails are stored in cookies, and the data is always running on the internet. do you think it is safe?

The database should be in a broad sense.
Although the speed of file system-based relational databases (SQL) may be slightly inferior, they all provide memory-based memory tables
Besides, the database has another branch: memory-based noSQL
Therefore, the additional overhead of database queries is negligible.

The process for determining whether a user is logged on is:
If the cookie ('uid') does not exist, log on to the system.
Otherwise, query the database and check whether the last logon location of the uid is the same as this one:
Confirm if they are the same
If there are different requests, a prompt will be issued. if there is a conditional transfer, login is required.

The MYSQL database will be queried every time. The logon address is generally an IP address.

Checks the user source to prevent CSRF attacks.
Generally, it is only performed on the page with the write action.

This is my practice.
1. check whether the user login is successfully connected to the database. for example, if the user ID, user name, and other information that needs to be judged are written into the session and cookies, set the cookie time (for example, 1 day ~ Two weeks later, you should select this one during login). In addition, I encrypt the data stored in cookies as a json_encode.
For example, {"uid": 1, "username": "fdipzone"} is encrypted as a reversible string.

2. the following situations may occur during user access:
1. determine whether a session exists-> Yes-> pass
2. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> Yes-> write the cookies to the session-> pass
3. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> no-> go to the login page.
4. determine whether a session exists-> no-> determine whether cookies exist-> no-> Jump to the login page

This is my practice.
1. check whether the user login is successfully connected to the database. for example, if the user ID, user name, and other information that needs to be judged are written into the session and cookies, set the cookie time (for example, 1 day ~ Two weeks later, you should select this one during login). In addition, I encrypt the data stored in cookies as a json_encode.
For example, {"uid": 1, "username": "fdipzone"} is encrypted as a reversible string.

2. the following situations may occur during user access:
1. determine whether a session exists-> Yes-> pass
2. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> Yes-> write the cookies to the session-> pass
3. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> no-> go to the login page.
4. determine whether a session exists-> no-> determine whether cookies exist-> no-> Jump to the login page

Your process does not seem to have searched the database, which is very economical, but there are vulnerability problems:
1. if the account is logged on normally at, the account is stolen at, and the password is changed. But he can continue to use the account and use it with the hacker.
2. assume that the user's password has been modified, but he has not logged out and logged on again, but he can continue to use this account.
3. the key issue is uncontrollable. if the user logs on at and the administrator bans his account at, he can continue using the account unless he exits and logs on again.

This is my practice.
1. check whether the user login is successfully connected to the database. for example, if the user ID, user name, and other information that needs to be judged are written into the session and cookies, set the cookie time (for example, 1 day ~ Two weeks later, you should select this one during login). In addition, I encrypt the data stored in cookies as a json_encode.
For example, {"uid": 1, "username": "fdipzone"} is encrypted as a reversible string.

2. the following situations may occur during user access:
1. determine whether a session exists-> Yes-> pass
2. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> Yes-> write the cookies to the session-> pass
3. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> no-> go to the login page.
4. determine whether a session exists-> no-> determine whether cookies exist-> no-> Jump to the login page

Your process does not seem to have searched the database, which is very economical, but there are vulnerability problems:
1. if the account is logged on normally at, the account is stolen at, and the password is changed. But he can continue to use the account and use it with the hacker.
2. assume that the user's password has been modified, but he has not logged out and logged on again, but he can continue to use this account.
3. the key issue is uncontrollable. if the user logs on at and the administrator bans his account at, he can continue using the account unless he exits and logs on again.

I judge that the closeuser part is performed after login. If none of the preceding steps are successful, you do not need to call closeuser for judgment.

By the way, there is a location where the session expires and then the cookies are written into the session. I will record the operation time into the db as the user's last online time. When determining whether the last online time is more than 10 minutes later than the current time, I will check the closeuser table and determine whether the table is blocked. If it is blocked, it will jump to the corresponding information prompt page. Check the database every 10 minutes.
Determine whether a session exists-> no-> determine whether a cookie exists-> Yes-> determine whether cookies are successfully decrypted-> Yes-> write cookies to a session-> pass

Then, check every 10 minutes

This is my practice.
1. check whether the user login is successfully connected to the database. for example, if the user ID, user name, and other information that needs to be judged are written into the session and cookies, set the cookie time (for example, 1 day ~ Two weeks later, you should select this one during login). In addition, I encrypt the data stored in cookies as a json_encode.
For example, {"uid": 1, "username": "fdipzone"} is encrypted as a reversible string.

2. the following situations may occur during user access:
1. determine whether a session exists-> Yes-> pass
2. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> Yes-> write the cookies to the session-> pass
3. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> no-> go to the login page.
4. determine whether a session exists-> no-> determine whether cookies exist-> no-> Jump to the login page

Your process does not seem to have searched the database, which is very economical, but there are vulnerability problems:
1. if the account is logged on normally at, the account is stolen at, and the password is changed. But he can continue to use the account and use it with the hacker.
2. assume that the user's password has been modified, but he has not logged out and logged on again, but he can continue to use this account.
3. the key issue is uncontrollable. if the user logs on at and the administrator bans his account at, he can continue using the account unless he exits and logs on again.

In fact, if a user forgets to log on to the internet cafe or other regions, then others can use the internet device to operate the content of his account. even if the user returns home, changing the password will not help, unless you log out and log on again (including shutdown/restart/completely close the browser process ).

This is my practice.
1. check whether the user login is successfully connected to the database. for example, if the user ID, user name, and other information that needs to be judged are written into the session and cookies, set the cookie time (for example, 1 day ~ Two weeks later, you should select this one during login). In addition, I encrypt the data stored in cookies as a json_encode.
For example, {"uid": 1, "username": "fdipzone"} is encrypted as a reversible string.

2. the following situations may occur during user access:
1. determine whether a session exists-> Yes-> pass
2. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> Yes-> write the cookies to the session-> pass
3. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> no-> go to the login page.
4. determine whether a session exists-> no-> determine whether cookies exist-> no-> Jump to the login page

Your process does not seem to have searched the database, which is very economical, but there are vulnerability problems:
1. if the account is logged on normally at, the account is stolen at, and the password is changed. But he can continue to use the account and use it with the hacker.
2. assume that the user's password has been modified, but he has not logged out and logged on again, but he can continue to use this account.
3. the key issue is uncontrollable. if the user logs on at and the administrator bans his account at, he can continue using the account unless he exits and logs on again.

I judge that the closeuser part is performed after login. If none of the preceding steps are successful, you do not need to call closeuser for judgment.

By the way, there is a location where the session expires and then the cookies are written into the session. I will record the operation time into the db as the user's last online time. When determining whether the last online time is more than 10 minutes later than the current time, I will check the closeuser table and determine whether the table is blocked. If it is blocked, it will jump to the corresponding information prompt page. Check the database every 10 minutes.
Determine whether a session exists-> no-> determine whether a cookie exists-> Yes-> determine whether cookies are successfully decrypted-> Yes-> write cookies to a session-> pass

Then, check every 10 minutes

If the session is used to store information, when the browser is closed (Including force closing the browser process), is the session expired?

Correct it.
When the session expires, the cookies are written into the session. In this location, the database is connected to determine whether the user is forbidden to log on.
The session has its own Expiration Time. Therefore, the interval between each database connection check is the session lifecycle.

Determine whether a session exists-> no-> determine whether a cookie exists-> Yes-> determine whether cookies are successfully decrypted-> Yes-> check whether logon is prohibited-> no-> write cookies session-> pass

Determine whether a session exists-> no-> determine whether cookies exist-> Yes-> determine whether cookies are successfully decrypted-> Yes-> check whether logon is prohibited-> Yes-> clear user cookies -> Jump to the notification page

This is my practice.
1. check whether the user login is successfully connected to the database. for example, if the user ID, user name, and other information that needs to be judged are written into the session and cookies, set the cookie time (for example, 1 day ~ Two weeks later, you should select this one during login). In addition, I encrypt the data stored in cookies as a json_encode.
For example, {"uid": 1, "username": "fdipzone"} is encrypted as a reversible string.

2. the following situations may occur during user access:
1. determine whether a session exists-> Yes-> pass
2. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> Yes-> write the cookies to the session-> pass
3. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> no-> go to the login page.
4. determine whether a session exists-> no-> determine whether cookies exist-> no-> Jump to the login page

Your process does not seem to have searched the database, which is very economical, but there are vulnerability problems:
1. if the account is logged on normally at, the account is stolen at, and the password is changed. But he can continue to use the account and use it with the hacker.
2. assume that the user's password has been modified, but he has not logged out and logged on again, but he can continue to use this account.
3. the key issue is uncontrollable. if the user logs on at and the administrator bans his account at, he can continue using the account unless he exits and logs on again.

I judge that the closeuser part is performed after login. If none of the preceding steps are successful, you do not need to call closeuser for judgment.

By the way, there is a location where the session expires and then the cookies are written into the session. I will record the operation time into the db as the user's last online time. When determining whether the last online time is more than 10 minutes later than the current time, I will check the closeuser table and determine whether the table is blocked. If it is blocked, it will jump to the corresponding information prompt page. Check the database every 10 minutes.
Determine whether a session exists-> no-> determine whether a cookie exists-> Yes-> determine whether cookies are successfully decrypted-> Yes-> write cookies to a session-> pass

Then, check every 10 minutes

If the session is used to store information, when the browser is closed (Including force closing the browser process), is the session expired?

Yes, then the cookie event will be judged.

Correct it.
When the session expires, the cookies are written into the session. In this location, the database is connected to determine whether the user is forbidden to log on.
The session has its own Expiration Time. Therefore, the interval between each database connection check is the session lifecycle.

Determine whether a session exists-> no-> determine whether a cookie exists-> Yes-> determine whether cookies are successfully decrypted-> Yes-> check whether logon is prohibited-> no-> write cookies session-> pass

Determine whether a session exists-> no-> determine whether cookies exist-> Yes-> determine whether cookies are successfully decrypted-> Yes-> check whether logon is prohibited-> Yes-> clear user cookies -> Jump to the notification page

If so, it seems that no SESSION is needed.
However, closing the browser makes it incredible that the session will expire...

Correct it.
When the session expires, the cookies are written into the session. In this location, the database is connected to determine whether the user is forbidden to log on.
The session has its own Expiration Time. Therefore, the interval between each database connection check is the session lifecycle.

Determine whether a session exists-> no-> determine whether a cookie exists-> Yes-> determine whether cookies are successfully decrypted-> Yes-> check whether logon is prohibited-> no-> write cookies session-> pass

Determine whether a session exists-> no-> determine whether cookies exist-> Yes-> determine whether cookies are successfully decrypted-> Yes-> check whether logon is prohibited-> Yes-> clear user cookies -> Jump to the notification page

If so, it seems that no SESSION is needed.
However, closing the browser makes it incredible that the session will expire...

Session is a session Process. it is normal to close the session and disappear.
Session is actually a cookie, but the survival time is relatively short, but it is safer to directly use the cookie. the client only saves the cookie value of one sessionid, and other content is saved on the server, the user reads the session content through sessionid during browsing.

Similar to html5 localStorage and sessionStorage

This is my practice.
1. check whether the user login is successfully connected to the database. for example, if the user ID, user name, and other information that needs to be judged are written into the session and cookies, set the cookie time (for example, 1 day ~ Two weeks later, you should select this one during login). In addition, I encrypt the data stored in cookies as a json_encode.
For example, {"uid": 1, "username": "fdipzone"} is encrypted as a reversible string.

2. the following situations may occur during user access:
1. determine whether a session exists-> Yes-> pass
2. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> Yes-> write the cookies to the session-> pass
3. determine whether the session exists-> no-> whether the cookies exist-> Yes-> whether the cookies are successfully decrypted-> no-> go to the login page.
4. determine whether a session exists-> no-> determine whether cookies exist-> no-> Jump to the login page

Your process does not seem to have searched the database, which is very economical, but there are vulnerability problems:
1. if the account is logged on normally at, the account is stolen at, and the password is changed. But he can continue to use the account and use it with the hacker.
2. assume that the user's password has been modified, but he has not logged out and logged on again, but he can continue to use this account.
3. the key issue is uncontrollable. if the user logs on at and the administrator bans his account at, he can continue using the account unless he exits and logs on again.

I judge that the closeuser part is performed after login. If none of the preceding steps are successful, you do not need to call closeuser for judgment.

By the way, there is a location where the session expires and then the cookies are written into the session. I will record the operation time into the db as the user's last online time. When determining whether the last online time is more than 10 minutes later than the current time, I will check the closeuser table and determine whether the table is blocked. If it is blocked, it will jump to the corresponding information prompt page. Check the database every 10 minutes.
Determine whether a session exists-> no-> determine whether a cookie exists-> Yes-> determine whether cookies are successfully decrypted-> Yes-> write cookies to a session-> pass

Then, check every 10 minutes

If the user has been on the operation page, then the SESSION has set a timeout Time. Will the time expire when it reaches?