Authentication Poll & Community Design [PLEASE JOIN!]

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Your authentication is...

Homegrown
61
91%
PEAR
4
6%
Non-PEAR but third-party
0
No votes
Borrowed from other software coexisting with app
2
3%
 
Total votes: 67

User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Aha. That's sounds pretty cool and convenient.

Have you considered implenting filesystem style permissions?
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

Yeah, but my past efforts with using that type haven't been met with very good results. They are somewhat difficult to use properly. Easy to use, but difficult to use properly. I'm going to design for that also. The permissions will be pretty diverse, while the access will only allow for roles and levels. The roles and levels will be separate from the permissions, but it should allow for any set or combinations as the developer wishes. Some applications, go for either roles or permissions, unless they are like phpBB and use both. I think using both allows for the best protection. To say who has access to what is all good but to be able to restrict someone from doing a task is even better.

Can you or do you really trust every Administrator? You better on some systems. Of course, you could give them a notch below admin, but then they feel that you don't trust them enough. If someone screws up, would it be wise to just 'fire' them or demote them? Or would it be better to just restrict them from ever doing that one task ever again?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Yeah, but my past efforts with using that type haven't been met with very good results. They are somewhat difficult to use properly. Easy to use, but difficult to use properly.
Ding! It's striking how often people just say "CHMOD it 777" and don't explain its implications.

If you're mixing up permissions and roles (which sounds like a great idea, by the way), you really should have a generic Authorizer that can be composed of PermissionAuthorizer or RoleAuthorizer or both. That way, the functionality is encapsulated and reused.
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

Ambush Commander wrote:Ding! It's striking how often people just say "CHMOD it 777" and don't explain its implications.
Thank god that Dreamhost doesn't force you to do that for your scripts! "Yes, I want you to rape me, drive it in really deep!" However I found that if you want to restrict the browser, you have to use 754, which seems to work for me at least. Or you could just place it underneath the public web folder.

Nah, I mean more to the effect of a three tier or point Permission: such as Read (Access), Write (Edit), Execute (Update). The read permission is set up for whether the user or group can access the page in the first place. The write is whether the person can edit any fields. The execute is what I have a problem with, it should probably be whether the person can edit another person's fields. For example, delete another's post. I don't know, I would rather have two permissions and combine the write and excute. If you provide any clearification on the uses of having three There is a difference between the two, but I have difficultly figuring out how to use both Write and Execute correctly. The Read is easy, unless I'm getting that mixed up also.
Ambush Commander wrote:If you're mixing up permissions and roles (which sounds like a great idea, by the way), you really should have a generic Authorizer that can be composed of PermissionAuthorizer or RoleAuthorizer or both. That way, the functionality is encapsulated and reused.
Yeah, that is a really good idea. My current design only allows for one role (either level or role) and one PermissionAuthorizer. I want to allow for a way to use multiple ones. Perhaps have an array for the role for when more than two are added. My prediction however is that I doubt anyone is going to use more than one role and one permission for most projects.

It seems like the best design for the Authorization is to not have a main class for functionality, but allow for the other classes to be used completely independent of each other. Would this be better design method?

Code: Select all

/**
 * @param string $username if empty then session is tried instead, else set else $user will be anonymous and could
 * be restricted even when signed in.
 */
$authorization = new AuthTools_Authorize_RoleAuthorizer([$username]); // implements AuthTools_Authorize_iAccessAuthorizer

$authorization->setPageName($pageName);

/**
 * Retrieves page from database and checks to see if username has the correct role to access page.
 */

if($authorization->isAuthorized() === false) {
    die("You don't have access here!");
}

/**
 * Checks to see if user has permissions at or above required to preform function.
 */

if($authorization->hasAccess($requiredRole) === true) {
    // Perform action
}
So the both the Role and Level Authorizers will have basic permissions for preforming actions. Not enough for more advanced pages. Now lets take a look at the AuthTools_Authorize_ActionPermission, which is like the hasAccess(), but checks for the action name and if the group or username can preform that action.

Code: Select all

$actionACL = new AuthTools_Authorize_ActionPermission([$username]); 
        // implements AuthTools_Authorize_iPermissionAuthorizer

if($actionACL->hasPermission($actionName) === true) {
    // Preform Action
}
The difference is that with ActionPermission you can set action down to the action preforms, while the above only checks to see if the person has the correct role. Oh yeah, ActionPermission also has the added benefit of automatically adding new actions to the database list for the admin panel to administrate, which would include an iterator.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Thank god that Dreamhost doesn't force you to do that for your scripts!
Well, actually I was having trouble with the post-commit hook, and I couldn't get dhapache into my group, so I was forced to chmod the entire live/ checkout of authtools 777. :-(
Nah, I mean more to the effect of a three tier or point Permission: such as Read (Access), Write (Edit), Execute (Update). The read permission is set up for whether the user or group can access the page in the first place. The write is whether the person can edit any fields. The execute is what I have a problem with, it should probably be whether the person can edit another person's fields. For example, delete another's post. I don't know, I would rather have two permissions and combine the write and excute. If you provide any clearification on the uses of having three There is a difference between the two, but I have difficultly figuring out how to use both Write and Execute correctly. The Read is easy, unless I'm getting that mixed up also.
Well, in the filesystem world, execute is very interesting special case, because anything that is out there, if you can read, you can execute, just make a copy.

I think, in the end, three points won't be sufficient for authorization purposes. The user will define all sorts of actions: read and write, of course, but also lock, change-rights, delete-user, block-user, super-moderate, etc. Read and write is a good start but it isn't the end-all-be-all solution. And we can safely ignore execute (I think) because we're not talking about a filesystem: we're talking about an application.

Of course, theoretically speaking all this deleting and blocking could be assigned to execute. But it could be a PITA to implement as a coarse-grained execute with finer rights within it.

Will reply to the rest later.
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

Ambush Commander wrote:
Thank god that Dreamhost doesn't force you to do that for your scripts!
Well, actually I was having trouble with the post-commit hook, and I couldn't get dhapache into my group, so I was forced to chmod the entire live/ checkout of authtools 777. :-(
Really? I didn't have to do that with my post-commit hook. Are you using a Perl Script, Shell Script, or PHP script to do it? I just used the svn export to the folder. Of course, I was using a compiled version of Subversion, but it shouldn't matter.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Shell. svn up.
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

I have been thinking of the Authorization System and I have came to a final draft version for how the system is going to work. The main class is going to be used, AuthTools_Authorize as well as other adapters or plugins to be added to it. I think I should have a skeleton up in a few days.

I also hope to have a skeleton or a working implementation of a Form Checking class. I thought it up while I was dustmopping, and I thought "Yeah! That would be nice."

AuthTools_Form (usage):

Code: Select all

$form = new AuthTools_Form();

// Validates against Sign In Form Key => Value Pairs.
if($form->validateSignIn() == true)
{
    $form->setSession();
    
    // AuthTools_SessionHandler::SetSession(); 
    // Or whatever the final method for setting the session is.
} else {
    $form->redirect($locationToRedirect);
}

// Validates against Register Form
if($form->validateRegister() == true)
{

    // Add User to Table Not part of AuthTools.

} else {

    $form->redirect($locationToRedirect);

}

// Configuration for settings, else it will use the default settings.
// Will use the added class before checking for the default class existance.
$form->changeSettings(AuthTools_Form_iAdapter $plugin);
It is all basically filtering, so if the coder does the filtering on their own then this class would be pointless. However, the processing will first look for filter functions, and if not found, will try Zend_Input_Filter, and if that isn't found then it will try the class filteration. The point is to make it as easy as possible for the filtering and testing the user data. It won't and shouldn't be mandatory that the person use the class and filter could be done manually or using another class package.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Not sure why you're checking equality to true, but let's see...

I'm not sure why the form needs to perform filtering, if anything, that's a problem for the controller, not the view. Authentication flow sort of explains the process, but essentially speaking, all processing will have been finished, and the form would then be simply querying for data in the $authentication_status object in order to determine what to do.

I'm a bit more interested in how the user would inject their own filtering schemes into credentials.
Post Reply