Some web pages need authentication to access. Only authorized users are allowed to read those pages. For example, wordpress back-end pages are prohibited from accessing by unauthorized visitors(you can refer to my article about wordpress login mechanism). Users get authorized via a login page. Today, we talk about the role of a php login page and its design.
A login page appears when visitors try to access protected content. Protected pages are usually put in one directory. Typically, user needs to input a user name and a password to log in. After login, the user won’t see the login page when he visits the protected resources again, if he does not close the browser. The user can also open the login page directly to complete the login process and access protected resources later. User can click a logout button to log out.
The code of login mechanism is usually separated into a file,i.e., login.php. Every page that need authorization includes the login page at the very beginning:
The reason of including the login.php before other content is to let login.php decide whether to output the other content of the protected page. So login.php must have a mechanism to know whether the current user has been authorized or not. If the user has logged in, login.php outputs nothing and continues to the other part of the protected page. Otherwise, login.php should output a login form and exit before other part of the protected content.
Typically, login.php should also handle the submit action after user fills the username and password, and clicks the submit button.
So login.php has 3 tasks:1)let authorized people continue to read the protected content;2)output a login form for unauthorized people;3)do the authorization after user clicks the submit button.
To remember these tasks more easily, we shortened them as 1)determine if login;2)display login form;3)do login
In the third task, login.php compares the username/password user inputs with those stored in the system, if match, sets a cookie as:
setcookie("auth", md5($username . $password . $salt));
and redirects to the original request url.
If not match, outputs the login form. Note that the login form is slightly different than the one user first sees it in task 2, in that it tells the user he needs to input the correct username/password. How does login.php know which version of login form it should output? It is easy! Just give the login button a name, i.e.,”login”, and check whether the variable $_POST[‘login’] exists. This way, login.php can know if the user clicked the submit button.
The first task is accomplished by the cookie set during authorization. login.php generates the value:md5($username . $password . $salt) using the username and password stored in the system, and compares it with the value in the cookie:auth. If match, this is an authorized user and let him in. If not match, execute task 2.
The logout function can be accomplished by login.php as follows. First, login.php knows it should execute the log out function by seeing a query parameter such as “logout”, then it clears the cookie auth:
and redirects to a specified page such as homepage.
In the above example, the login mechanism is implemented by a cookie set in task 3, which is checked in task 1. The login can also be implemented by SESSION mechanism as follows. Task 3 sets a session variable:_SESSION[“uid”]=$uid after verifying the login user successfully, i.e., the user name exists in the system database and the password provided by the user is the same as stored in the system database. Task 1 can be simplified as checking if the session variable _SESSION[“uid”] exists. You should handle the redirection carefully. Protected pages need to be redirected to the login page if user has not logged in. But the login page itself should not be redirected to itself if _SESSION[“uid”] does not exists, otherwise, the redirection would be endless.