Authentication Dialog Displayed by Browser in Response to Authentication Challenge from Server
A good strategy for authentication is to not do it in your application. It is usually best done by the web server or related software, which is specially built for the purpose and can take advantage of an existing user repository. This way you can pass the code to your system administrator and let him or her set up the appropriate authentication method for your organization. Your PHP program can then access the identity of the user than has authenticated with the $_SERVER['PHP_AUTH_USER'] variable.
PHP is most often an Apache module. As an example for authorization you may use the Apache .htaccess file mechanism to protect access to PHP scripts within a certain folder. The following PHP script will get the name of the user after they have authenticated to Apache and print it out with a hello message.
You can also programmatically restrict access to a page forcing the server to send an authentication dialog to a user by including a WWW-Authenticate header as in the example below.
This code will prompt the user for username and password with the standard dialog. In response to this authentication challenge the browser will show a dialog like that below.
If the user presses cancel then the text 'You must sign in to perform this action. Register.' will be displayed, as shown below.
If the user clicks OK then the user name and password will be displayed, whatever it is. To work properly, this should be included on the page before any HTML text. You need to replace the contents of the else block with your own code to do the authentication check.
Basic authentication can be replaced with digest for more secure transport of the password.
If you are requiring authentication to your web application it is most likely that you will want to store data during
a user's session. This is most often transaction data collected over multiple screens. The global variable
$_SESSION, an associative array can be used to do this. You need to begin the session with the
function session_start() before $_SESSION is available. However, you can avoid
this by setting the session.auto_start to 1 in php.ini. Here is an example that
increments the count variable each time the user views the page within at the same session.
There are two options to pass the session ID between the browser and the server: cookies or URL rewriting.
URL rewriting embeds session data in all the URL's. Cookies are preferred because they are more secure
and cleaner. URL rewriting is vulnerable to a attacker discovering session ID's from server logs
and caches. The disadvantage of cookies is that some users may disable cookies. Note that, in the code
above, the function session_start() must be called for each reqeust where you want to
store data to or retrieve data from the session. URL rewriting can be avoided by setting the
the property session.use_only_cookies to true. This can be done in either the
php.ini file or in code with the call ini_set("session.use_only_cookies", true).
By default session data is stored in files, one file for each user session. The directory in which the files are saved can be configured via the php.in file. Other options are to store the session data in memory or a database. Other configuration options are available for how long a session can last and how they are cached.
There are no user comments.
Please send ideas and opinions by email at alexamies@gmail.com.