PHP
  Home arrow PHP arrow Page 8 - User Authentication With Apache And PHP
Dev Shed Forums  
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Smartphone Development  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Mobile Linux  
App Generation ROI  
IBM® developerWorks  
Forums Sitemap  
E-Commerce Hosting  
Linux Web Hosting  
Managed Hosting  
Small Business Hosting  
VPS Hosting  
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid  
Request Media Kit
Contact Us  
Site Map  
Privacy Policy  
Support  
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
PHP

User Authentication With Apache And PHP
By: The Disenchanted Developer, (c) Melonfire
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: starstarstarstarstar / 56
    2002-03-13


    Table of Contents:
  • User Authentication With Apache And PHP
  • Back To Basics
  • The Right Creds
  • Hidden Costs
  • Logging In
  • Rank And File
  • Heavy Iron
  • Sock It To Me, Baby!
  • Time To Live
  • A Stitch In Time
  • Closing Time

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      error-file:tidyout.log Del.ici.ous error-file:tidyout.log Digg
      error-file:tidyout.log Blink error-file:tidyout.log Simpy
      error-file:tidyout.log Google error-file:tidyout.log Spurl
      error-file:tidyout.log Y! MyWeb error-file:tidyout.log Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article

     
     
    ADVERTISEMENT


    User Authentication With Apache And PHP - Sock It To Me, Baby!
    ( Page 8 of 11 )

    So that takes care of authentication via flat file and database. There is one more authentication option, though it's not one that's very common in the Web environment. In the arena of networked set-top applications, there often exist proprietary authentication schemes, and proprietary methods of performing user authentication.

    In one such system that I worked on, authentication took place via a socket server listening on a specific port for connections. This socket server could accept a username/password combination, in the form "username:password" and return an appropriate result code depending on whether or not the validation was successful.

    In such a system, the authenticate() function in the "login.php" script could be further modified to use a socket connection to perform the validation, rather than a database or a file. Take a look at what this might look like:

    <? // login.php - performs validation $status = authenticate($f_user, $f_pass); // if user/pass combination is correct if ($status == 1) { // initiate a session session_start(); // register some session variables session_register("SESSION"); // including the username session_register("SESSION_UNAME"); $SESSION_UNAME = $f_user; // redirect to protected page header("Location: /inner.sanctum.php"); exit(); } else // user/pass check failed { // redirect to error page header("Location: /error.php?e=$auth"); exit(); } // authenticate username/password against data from a socket connection // returns: -1 if user does not exist // 0 if user exists but password is incorrect // 1 if username and password are correct function authenticate($user, $pass) { // where is the socket server? $host ="192.168.1.99"; $port = 1234; // assign authentication status -1 $result = -1; // open a client connection $fp = fsockopen ($host, $port, $errno, $errstr); if (!$fp) { return $result; } else { // get the welcome message fgets ($fp, 1024); // create the input string $message = "$user:$pass"; // write the user string to the socket fputs ($fp, $message); // get the result // this will be 0 or 1 $result .= fgets ($fp, 1024); // close the connection fputs ($fp, "END"); fclose ($fp); // trim the result $result = trim($result); } return $result; } ?>
    Fairly simple, this. A socket connection is opened to the socket server from the PHP script (which acts as a client), and the form data transmitted to it via a call to fsockopen(). The socket server then internally runs a proprietary validation routine to test whether or not the data passed to it is correct, and returns a result code to the client. This return value can be intercepted via the fgets() function, and returned to the main program, which then again makes the decision of what to do next.

    As I said, it's unlikely that you'll ever find yourself using this. It's included here for illustrative purposes only, as an example of yet another way of performing authentication in a proprietary environment.{mospagebreak title=Entering The Inner Sanctum} So that takes care of the initial verification. Assuming the user has been successfully validated, all three versions of the "login.php" script above would create a new session and redirect the user to the protected page "inner.sanctum.php".

    Now for the second part of the validation, and the one that you might not have thought of. Every protected page must itself include program code to ensure that only authorized users have access to it. Without this code, it would be possible for anyone to access the page directly, just by typing the URL into their browser's address bar.

    Here's what the code for inner.sanctum.php looks like:

    <? // inner.sanctum.php - secure page // session check session_start(); if (!session_is_registered("SESSION")) { // if session check fails, invoke error handler header("Location: /error.php?e=2"); exit(); } ?> <html> <head> <basefont face="Verdana"> </head> <body> <center> Welcome to the inner sanctum. We've been waiting for you. </center> <p align="right"> <font size="-1"><a href="logout.php">Goodbye</a></font> </body> </html>
    Note the code right at the top of the page. I'm first checking to ensure that a valid session exists for this user, and only proceeding to display the page if it does. If a valid session does not exist, it would imply that the user was either unable to log in successfully, or that (s)he bypassed the login screens altogether and attempted to access the page directly. In either case, access should be denied - which is why I've used the header() function to redirect the user to the error page immediately.

    This is a very primitive check, of course - I'm merely testing to see whether a session exists. In the real world, you'd typically want to add a few more checks, such as verifying the user's permission level or role (common in the case of multi-tiered, group-based systems).

    In order to understand the difference, try accessing the page above by directly typing the URL into your browser's address bar without logging in first. You should not be allowed access. Then comment out the PHP code at the top of the script, and try again. You'll see that, this time, you can access this "protected" page without needing to log in first.

    Here's what the page looks like:



     
     
    >>> More PHP Articles          >>> More By The Disenchanted Developer, (c) Melonfire
     

       

    PHP ARTICLES

    - Using Directory Iterators to Build Loader Ap...
    - Using the spl_autoload() Functions to Build ...
    - Working Out of the Object Context to Build L...
    - Using the _autoload() Magic Function to Buil...
    - The Destruct Magic Function in PHP 5
    - The Autoload Magic Function in PHP 5
    - Developing a Recursive Loading Class for Loa...
    - The Sleep and Wakeup Magic Functions in PHP 5
    - Using the Clone Magic Function in PHP 5
    - Including Files Recursively with Loader Appl...
    - The Call Magic Function in PHP 5
    - Designing a Captcha System with PHP and MySQL
    - Using Static Methods to Build Loader Apps in...
    - The Isset and Unset Magic Functions in PHP 5
    - Advanced PHP Form Input Validation to Check ...





    © 2003-2009 by Developer Shed. All rights reserved. DS Cluster 3 hosted by Hostway
    Stay green...Green IT