You should store the time of the user’s last action/navigation and IP.
So you could check with the time that your session remains alive and allow only the access of those who are logged in at that time and still inform if there is an attempt to login at another location, that the user is already logged in to another computer and provide even the IP.
Example, if your session is alive for 30 minutes, when the user enters the system, or navigates between pages, do some action, you save the time in the database and the IP.
| Horario | Endereco de IP |
|------------------|------------------------|
| 2014-11-07 08:20 | 200.100.50.10 |
When logging in or changing a page or any action on the system, you update this data, always following the session expiration time.
If IP of the new access = IP of last access, access must be allowed as it is the same. Take the new time and update:
| Horario | Endereco de IP |
|------------------|------------------------|
| 2014-11-07 08:40 | 200.100.50.10 |
If it is IP of the new access other than IP of last access, then check the times: time of new access must be greater than the last login time + session life time.
Ex.:
Novo Acesso Ultimo Acesso Tempo Vida Sessao
2014-11-07 08:55 2014-11-07 08:40 + 30
2014-11-07 08:55 2014-11-07 09:10
as 08:55 is prior to 09:10 (considering the clear dates) means that you have another active session and the user cannot take any action, including login.
Let’s assume now that he tried to access the 9:15 am
Novo Acesso Ultimo Acesso Tempo Vida Sessao
2014-11-07 09:15 2014-11-07 08:40 + 30
2014-11-07 09:15 2014-11-07 09:10
The new access was made after the expiration of the active session of the other user so he can log in/do actions and the bank is updated.
| Horario | Endereco de IP |
|------------------|------------------------|
| 2014-11-07 09:15 | 100.200.50.40 |
When the user logout, these fields would be set to null
or, better than that to facilitate comparison, for values default where access was possible.
Ex. in the case of logout:
| Horario | Endereco de IP |
|------------------|------------------------|
| null | null |
With values default (facilitating comparison in any situation, avoiding exceptions in programming):
| Horario | Endereco de IP |
|------------------|------------------------|
| 2000-01-01 00:00 | 0.0.0.0 |
In case the logged-in user loses the connection and his IP is modified he loses access and can only access again when his session expires, that is, in my example, 30 minutes. For this, the ideal is to evaluate the session time that will be used, making a balance between the time that the user needs to have between an action and another until the session expires and the time that the user can expect if this happens (change of IP and need to wait for the session to expire). It is believed that short sessions are safer. You can apply 5 or 10 minutes to shorten this time and prevent the user from staying logged in if he leaves and does not logout.
You can also, to avoid this, use a key generated in the login step and store it as a cookie, replacing the IP identification with the generated key, thus circumventing that part of the IP. Remembering that cookies are editable, with some maneuvers it would be possible to access from more than one location. I prefer the approach using IP.
This is one of the ways of doing it, the various possible ways of implementing.
And what’s the problem?
– Beterraba
I wanted to store inside the table, if the user is connected or not. For dps to deny entry, call if you have the same user if they are on the system (login).
– akm
is basically this, you create a field to store whether you are logged in or not, when logging in, you check if the field is "true", if you are not you create the session, and exchange the value of that field, if you are, you send a message that this user is already logged in to the system, and it is important to remember to return the value of this field to "false", when the session is destroyed.
– Enzo Tiezzi
The concept you already have, you missed only condition the creation of the session variable with this field that you are bringing when consulting the user’s existence (so I hope).
– Bruno Augusto
@Enzotiezzi and if the user does not log in and the session expires can never log in?
– Jorge B.
True, but also, with the lemons I had, at most I could make lemonade.
– Bruno Augusto