Identifying Users: In building an administrative back-end to your database, you are creating an opportunity for malicious users to alter or destroy that database. In building an e-commerce site, you are creating a chance for a theif to steal goods using someone else's identification or by otherwise claiming a fictious identity. To prevent such fraud, you need ways to identify a user and to verify that future visits from someone claiming to be the same person are authentic. Otherwise, you will want to deny them access to various pages of your site.
The internet provides some information about users. Namely, it provides their IP address (so that the server knows where to respond), and also information about browser type, and often more (screen size, for example), but personal information is available only if the user volunteers it. You will have to ask. You then have different possible ways to adjust access and service for that particular user.
Access Control: Basic authentication requires a user to acquire and use a unique ID and a secret password. You can hard code this in PHP because the PHP script won't be sent to the browser, but the password would be transmitted in plain text (even if hidden by use of a POST method, it is interceptable), and it would be difficult to use more than a handful of id's and passwords this way (see listing 16.1, p. 359-361.)
Stored passwords: Normally, multiple users and passwords are written in a separate file, usually a database table. A preset list of users and passwords is queried to see if there is a match to the id and password that the user provides. If not, the error message should not indicate specifically that the id or the password was incorrect, as this would indicate at least one of the two safeguards was now known.
Encrypted passwords: Encrypt a password using sha1() (sha-one), using the function string sha1 (string str [, bool raw_output]), which returns a pseudo-random 40 character string; if raw_output is true, you get a 20-character string of binary data. You cannot work backward from the string to the password, but the string will generate the same password each time. You can generate it, and then use that in a hard code comparison (p. 365), so that the password itself never appears in a code. The passwords would then be stored as 40 character strings in the database, and the SQL string would encrypt the user-provided password before looking for matches in the database (p. 365).
Basic Authentication: After a user has been identified by id and password, you have two mechanisms for maintaining the state of authentication between subsequent page loads (so that the user doesn't have to identify themselves on each page). One is to use an intrinsic HTTP feature, basic authentication; This isn't optimally secure, for reasons given on p. 366-367, but for many situations, it is acceptable. It can be triggered in one of three ways:
- Use a PHP script (listing 16.4) on every page to detect server type (Apache vs. Microsoft's IIS, internet information system) and then run a query against the database of id's and pw's.
- Apache uses a flat file that stores users and passwords. This is checked on each page. Code is listed on p. 369-372.
- IIS uses a flat file called protected>content.html in the web site panel to list authenticated users. These are uses created in IIS (e.g., each student in this class), which requires an administrative action on the server.
Bottom Line: My suggestion is that you skip all of this nonsense and proceed to chapter 22, where you'll set a simple session variable, check it quickly on each subsequent page, and write a lot less code!