Why do I log in to a site in a, someone else opens the site in B, which shows my account is logged in?

Q: Why do I log in one place (such as Beijing) after someone else logs in to the site in another location (such as in Shanxi) and displays my account directly?

For example, I login in Beijing Segmentfault, other people in Shanxi opened Segmentfault official website, see the site is already in the state of being logged in, the display is my account, perhaps I have not clicked the Exit button may be directly close the browser, or other.

There is currently a suspicion that the login is checked for automatic login or not by clicking the Exit button, but the problem has not been tested yet. Hope to have encountered such problems of children's shoes to give the idea or solution direction.

Reply content:

Q: Why do I log in one place (such as Beijing) after someone else logs in to the site in another location (such as in Shanxi) and displays my account directly?

For example, I login in Beijing Segmentfault, other people in Shanxi opened Segmentfault official website, see the site is already in the state of being logged in, the display is my account, perhaps I have not clicked the Exit button may be directly close the browser, or other.

There is currently a suspicion that the login is checked for automatic login or not by clicking the Exit button, but the problem has not been tested yet. Hope to have encountered such problems of children's shoes to give the idea or solution direction.

Because the server uses the session to save your login status.
Before the session expires or you actively log out, the server will always assume that you are logged in and show up in the component of the logged-on user on the page.

It seems that I understand the wrong question ...

1. The browser has a cookie function. To avoid repeated login actions, the website usually logs the login information to the cookie at login so that the next time the page is opened, the cookie can be used and the login is omitted.
2. When you log in, you will typically have the option to keep the user logged on for as long as you want, and the same browser will automatically log in to the account, even if you have closed the browser.
3. If you don't want to log in automatically, you can choose not to log in automatically when you log in, you can log out manually, or you can clean cookies.
4. Generally cross-browser (cross-core) cookies are not universal. However, it is still possible to force synchronization, such as firing IE extensions.
5. General cross-machine synchronization is uncommon, but many browsers still have the ability to synchronize cookies with extensions or features.
6. To exclude their login, cookie synchronization and other situations, there are still automatic login, which is basically the site design problems. The general cookie does not directly store the pre-logon information (such as the user name password, even if it is encrypted), but instead stores the post-login information, usually called tokens. Poorly designed systems may have a token conflict or read a recognition error, resulting in a login to someone else's account. There have been many such chestnuts in MS ... For example, 12306 gods and Horses ...

This question is not about cookies. It's obvious that SessionID is a serial number.

The main situation is: When you open this site, the server sent you a random number, as your identity card, such as:
123456789, because each person's number is random, so it can be considered unique, but not absolute, there may be a problem with the random algorithm used by the website program, resulting in the same random number generated, that is, the number of 123456789 to another person, And then I thought you two were the same person.
Listen to the news that the slag Wave micro-Bo appeared this situation ha, should be too many users lead to a greater chance of conflict ...
To verify that this is not the case, you can use the View cookie tool to see if it is duplicated on both sides.

Another: The so-called session hijacking, is such a principle: malicious users through some means, such as XSS, get to the user cookie SessionID, have this ID, for the program is to represent you are this user, and then the hacker can exercise all the rights of this user.
So when SessionID is placed in a cookie, remember to set it to httponly and encrypt the transmission.

Add: The upstairs said cache is also possible, may be some war five slag class CDN or ISP to cache your request results, but this situation should not be high, so that more than one person affected, through this CDN or ISP users will be affected.

You do not log out of the site is not actively delete your cookie, the cookie has not expired, your login status will not change

First, the server is not able to identify the user without discussing cookies. This IP login does not mean that there is only one host after this IP, nor does it mean that the IP represents a host with only one browser.

So, the cookie comes out. When you first visit (or when you log in) give you a cookie, each time you request to bring this cookie, the server receives the value of the cookie later, find the cookie corresponding to the record, look at your information (in this case, see if you have login).

Of course, each cookie in the browser has an expiration time and the cookie is deleted directly after it expires. Therefore, on the server side, each cookie corresponding to the storage file (usually called Session ) also has a failure time, is also the failure to delete the session directly.

So, obviously, the client cookie and the corresponding server side session have a missing, the server has no way to know your login status.

The final reason is (in fact, everyone has said): Browser Cookie does not expire, the server session does not expire.

Session is the only recognition, so it must be the session does not expire under the premise of the remote user access, the cookie marked the session of the SessionID, only such a possible bar

Tell the truth.

You forgot a question.

That's the problem with the website itself.

For example, the first time a university visited its mobile phone official website

Be randomly logged in to a user directly

I'm just offering a possibility.

This problem was previously encountered in the 17K above, I set the automatic login, there are times to open the site directly display login is someone else's account

The upstairs few seem to have not seen the problem clearly.
The owner has said that the substitution in the field landing, so there is no problem of cookies.
It's not a question of the session.
And the procedural problem is the biggest possibility!

Let me say a possibility.

Before we wrote a Web site This problem, others do not log on automatically appear in someone else's account.

Check it out, we are a project of the school, by the School Network Center export Server Cache page.

We'll just have to force ourselves to add No-cache.

