Reply to Re: Brackets across includes

Your name:

Reply:


Posted by Chung Leong on 11/24/46 11:56

pengypenguin@gmail.com wrote:
> Hello all,
>
> I am trying to create a user authentication system, and I would like to
> separate the authentication code into include files. As I see it, the
> basic flow would go something like this:

Before you start coding, try to get your concepts straight first.
Authentication determines the identity of the user. Authorization
determines if the user has permission to do something. These are
separate concepts and should be implemented as separate procedures.

When you restrict access to a page, the question you ask is "Is this
visitor permitted to view this page?" "The visitor is Joe Black"
clearly isn't a sufficient answer. To answer the question, you might
need to know who the visitor is--or might not. Authorization could be
granted on the basis of IP address for instance, or it could be granted
based on an authorization token received from a trusted source. It
could even be based on the time of day (e.g. "visitors are allowed from
8am-6pm").

To reiterate: identity =/=> permission. Too many people get this wrong.

As Alvaro noted, you should use functions. Performing tasks by
including files is a primitive, stupid way to program. Include files
should only contain function/class declarations that're used by the
actual, executable script.

Here's an example of an authorization scheme. At the top of every page,
you would have something like this:

<?php

require('global.php');

CheckAuthorization(0);

/* do stuff */

?>

Again, the question we're asking is "Is the visitor permitted to view
this page?". It's a authorization question--not authentication--hence
the function name. The parameter is the authority required for a
particular page. Here we'll use a simple numeric system. Zero authority
means the page is unrestricted. The function call might seem redundant
for this case, but it's useful to have the system cover the whole site.
If in the future you need to completely deny access to, say, a
particular IP address, the hooks are in place already.

The CheckAuthorization function would look something like this:

<?php

function CheckAuthorization($required_level) {
$visitor_level = GetVisitorPermissionLevel();
if($visitor_level < $required_level) {
header("Location: login.php");
exit(0);
}
return true;
}

function GetVisitorPermissionLevel() {
if(isset($_SESSION['visitor_permission_level'])) {
return $_SESSION['visitor_permission_level'];
}
return 0;
}

function AuthorizeVisitor($level_granted) {
$_SESSION['visitor_permission_level'] = $level_granted;
}

?>

The logic is fairly simple: If the visitor doesn't have the necessary
authority, then he's send to a login page. During the login process,
AuthorizeVisitor() would be called with a certain permission level,
perhaps retrieved from a database, once the visitor's identity is
acertained. The code might look something like this:

if(AuthenticateUser($_POST['login'], $_POST['password'])) {
$user_level = GetUserPermissionLevel($_POST['login']);
AuthorizeVisitor($user_level);
}

The key, again, is that authentication is separate and distinct from
authorization. Keeping the distinction make the process clearer and
leaves options open for changes down the line. For instance, it'd be
relatively straight forward to extend the example above to support a
second method of authentication (e.g. HTTP).

[Back to original message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация