How does the logic of a simple login system with "access all devices"?

Warning: count(): Parameter must be an array or an object that implements Countable in /home/styllloz/public_html/qa-theme/donut-theme/qa-donut-layer.php on line 274
0 like 0 dislike
While using only PHP, MySQL, sessions and cookies (without redis's, memtsov, etc.).
Just when I started to write the password recovery (essentially resetting the new mail comes to the user), understand that the logic here should be "output to all devices" and how to organize, I do not understand.

Admin to this, as it is not particularly needed, so use them only for the smallest of needs with a simple entry auth=true in the session. At the browser session is lost. You know that you can increase the life of the session, but it seems like not recommend, write it and then to restore them according to the cookies(optional, probably still a set, not a session) or tokens in the database (not face). Here I wanted to ask what where to write something in the end so that you can later distinguish the user's authorization across devices, and that time they could carry when you reset the password?

Yet figuratively, you can imagine something like this to submit:
1. Autoresume -> fill session recorded additional (long term, eg 3 days) cookie with a random string (mycoockie = "dsf34Nrty4d4dftlk5r4g5") to restore the session recorded to the database table sessions the same string ("dsf34Nrty4d4dftlk5r4g5") and the ID of the user who owns the session.

open trail. page:

2. If there is a session -> work (or too constantly to validate to any current data in the database, because maybe I'm the attacker and the real user used the password reset, i.e. should I just throw).

3. If missing (closes the browser, or 24 minutes of inactivity that's kind of the default for sessions), check the cookie (mycoockie), and if it is some kind of random-string. -> check the presence of this random string in the DB, if found, then restore the ID on the opposite to this line the data of the user.
by | 19 views

2 Answers

0 like 0 dislike
I have implemented the following:

There in the database table sessions fields current_session, long_session, user_id, and login_time.
Upon successful login generates two random strings. The first is written in standard PHP session and will current_session. The second is written to the user session cookie, and the hash of this string will be long_session. user_id - the user ID, login_time - time login.

Check whether the logged in user, as follows:
1. If the user has an active PHP session, check if it current_session if Yes, then the user is logged in.
2. If the user has no current session, but session is established cook, then searching for hash it in the database. If the entry is, and since the last login has passed is less than the specified amount of time (I use less than three months) then user_id take the rest of the data user and create the current session, the user is logged in.

When you logout just cleaning up the current current_session and long_session. If you want razlozhenii everywhere, cleaned all the value for user_id.

This approach allows us to strictly manage the sessions with a DB, but a standard mechanism for PHP sessions allows you to store a variety of information, like a csrf token, not littered base.
0 like 0 dislike
Change token accounts on the server and given the next request.

Related questions

0 like 0 dislike
2 answers
0 like 0 dislike
2 answers
asked May 22, 2019 by savfa
0 like 0 dislike
2 answers
asked Apr 11, 2019 by Denis9999
110,608 questions
257,187 answers
40,796 users