Authentication Poll & Community Design [PLEASE JOIN!]
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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?
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?
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Ding! It's striking how often people just say "CHMOD it 777" and don't explain its implications.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.
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.
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.Ambush Commander wrote:Ding! It's striking how often people just say "CHMOD it 777" and don't explain its implications.
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.
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.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.
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
}Code: Select all
$actionACL = new AuthTools_Authorize_ActionPermission([$username]);
// implements AuthTools_Authorize_iPermissionAuthorizer
if($actionACL->hasPermission($actionName) === true) {
// Preform Action
}- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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.Thank god that Dreamhost doesn't force you to do that for your scripts!
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.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.
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.
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.Ambush Commander wrote: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. :-(Thank god that Dreamhost doesn't force you to do that for your scripts!
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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):
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.
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);- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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.
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.