Re: Brackets across includes
- From: "Chung Leong" <chernyshevsky@xxxxxxxxxxx>
- Date: 24 Aug 2006 14:29:06 -0700
pengypenguin@xxxxxxxxx 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).
.
- References:
- Brackets across includes
- From: pengypenguin
- Brackets across includes
- Prev by Date: Re: Limit folder (with subfolders) capacity
- Next by Date: Re: Srv OS compatibility and $_ENV
- Previous by thread: Re: Brackets across includes
- Next by thread: Re: Brackets across includes
- Index(es):
Relevant Pages
|
