M
M
mrWan2018-04-23 16:38:46
PHP
mrWan, 2018-04-23 16:38:46

What is the best way to login to the site?

I'm authorizing the site.
After reading a couple of articles, I came to the conclusion that everything should be done in the following sequence:
1. Checking a specific session, if it exists, we give access
2. If the session does not exist, then we check the cookies, if there are necessary cookies, then we create the necessary session and go to step 1.
3. If the cookie does not exist, then we ask you to enter your login and password, after which we create a session and go to step 1, if we check the "remember me" box, then we create the necessary cookies and go to step 2.
There are a lot of questions. From "what data to store in sessions, cookies from where to get them, etc.

Answer the question

In order to leave comments, you need to log in

5 answer(s)
Y
Yan-s, 2018-04-23
@Yan-s

If you need an implementation: put a ready-made solution.
If you are interested in figuring out how to do it right: take a ready-made solution, see how it works.

A
Arris, 2018-04-23
@Arris

https://github.com/PHPAuth/PHPAuth
Recommended.

F
FanatPHP, 2018-04-23
@FanatPHP

The session stores the minimum user id.
The cookie has a unique value, uuid for example (of course, it is generated anew each time) + it is also put into the base for verification.

V
Vladimir Dubrovin, 2018-04-24
@z3apa3a

If this is a simple, non-distributed site for which heavy loads and scaling are not planned, then usually after entering the login / password, a session cookie is set (with the HTTPOnly flag). For all requests, the validity of the cookie is checked. It is possible to:
1. Use standard PHP sessions/session cookies, when authenticating by login and password, set the authorization flag and user id for the session. The easiest and most common way.
2. Set your cookie and check cookies for validity in the database on each request. Pros - the ability to create persitent sessions, it is easy to end the session - the session is invalidated in the database. Cons - access to the database on each request.
3. Issue cookies with the server's signature, check the signature on requests without accessing the database. Minus - you can not invalidate cookies on the server side.
4. Use a session cookie, which is given as a login and password and stored in the database + an access cookie, which is issued according to the session cookie and signed, include a timestamp in the access cookie so that it quickly becomes obsolete, when it becomes obsolete, check the session cookie in the database and put down new access cookie. So you don’t have to climb into the database on every request, only when the access cookie goes bad.
If a distributed, scalable service is required, things get more complicated. For example, we have implemented such a scheme.

S
Stalker_RED, 2018-04-24
@Stalker_RED

It's better not to experiment with security if you don't understand how it works.
Take a standard session, check if the user_id is there.
If not, show the login/password entry form.
If the user has entered the correct password, write to the session user_id
That's it.
When using standard sessions, cookies will be set automatically, you don't have to think about them. (Except to check if it's worth "session.cookie_httponly on" in the settings).
No tokens need to be written to the database until you understand why you need it.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question