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 »

Take your time. (I myself somewhat dread having to back through all the notes and organizing them in a better manner).
However, one more thing. I believe if you fetch all of the data first, MySQL or the database sends it all back to PHP, which can be a huge chunk. That chunk has to be processed and go through the pipeline to the server PHP is on (if they are separate servers). I'm probably talking out my ass, but other methods PHP calls for the first row and MySQL sends just that row and then moves the counter up to send the next row that meets the criteria.

So it breaks down to sending all of the data at once or just a tiny bit at a time. You will eventually fetch all of the data, but if you so happen that you don't need to go any further after say row 1000 out of a million, then you saved yourself a lot of data that would have otherwise had been sent.
Doing, that's why you use LIMIT.
No One uses Reset Anymore
Teehee, I was wondering that too. But it doesn't hurt (unless you accidentally click it).
How about a Register button instead that transfers to another page (using JavaScript?) that will allow them to register.
No need for JavaScript, but I forgot that you need the link to the register page. That's another configuration thing.

I agree with everything else you said. I've actually got more notes, but they're not typed up yet.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Sort of need notes - 18 pages? :)

Just a general question - what is the reason for the DB focus? Sounds like a stupid question (maybe it is) but how would the DB class interact with the Authentication class(es)? Will this be an Authentication dependency?
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

My take however is that it would be better for the developer to use the Database Version.

But

I would support the decoupling of the database from the general Authentication Classes, so if I want to shoot myself in the foot by using text files, I can. Other than that some people will want to use hard coded usernames and passwords from within the script and support for that will also be nice to have.

Focusing on database design does allow for the development to pick up and go so where for when the time does come to allow for shooting one's self in the foot or another means.

Limiting the scope of the project allows the speed up of the project, but it sort of has to be easy to modify and add things. If the entire thing has to be rewritten for flat files or XML storage, then what is the point? The point is that most people will use DB access for authentication and it makes sense to have support for it.

------

That isn't what you meant, I suppose, I hope it isn't. However, it should not be hard to use the DB Mapper classes with say PDO or ADO (Lite).
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Sort of need notes - 18 pages?
I think you can safely ignore most of the previous discussion. It's extremely difficult to follow because it's highly unstructured (a problem people are also running into over at our other community-based project. I'd like it a lot if you read my notes, but besides organization into sections, they're also unstructured. When time permits, I'll organize them into pages, grouped by their problem domain. Then you only have to read what interests you.
Just a general question - what is the reason for the DB focus? Sounds like a stupid question (maybe it is) but how would the DB class interact with the Authentication class(es)? Will this be an Authentication dependency?
The authentication classes will have a dependency on our DataFacade interface. This interface defines the most minimalistic store and retrieve routines necessary in order to let authentication work. It would also be partitioned into various segments, allowing a file-based data storage to only partially implement the lowest level, after all, it's pretty darn difficult to do certain things with files (as opposed to databases).

The authentication model classes will actually have no dependency to the DB class. :twisted:

Ideally speaking, I would build a whole battery of Mappers, and directly query the database to translate into objects, but this would make overloading the mappers with file-based mappers exceedingly difficult (due to their generalized nature, you would basically have to reimplement databases).

If anyone can prove me wrong, please do so. I'd love to use mappers on this project.

Santosj, I agree with what you said, and I'm simply addressing another part of the problem.
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

Would it be possible for you to export the trunk to another folder with PHP 5 support so that we can run the tests on the server and test them after the revision has been made?

I know that the tests should be run before the commit but, it would be quicker to find other issues from the global contribution of others who don't or haven't tested (those like me and I can change baby, I promise).

I have the post commit export script for Subversion. It wasn't hard to do, just one line of Shell Script. It will be in the /home/username/svn/projectname/hooks/post-commit. On a side note, you can also create a pre-commit that can check to see if a message is added to the commit and stop the commit.

When you have time and get back?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Yes, that would be pretty marvelous (although that also means that you can compromise my server by uploading bad code (yes I'm paranoid)).

I've pretty much have got everything I need to maintain the server right now, so yes, I can check out the script.

Of course, you could always check out the entire trunk. ;-)
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

AuthTools_ACL

Post by santosj »

AuthTools_Acl is an interface for which the other authorization classes will implement. This allows for instanceof AuthTools_Acl for checking to make sure the classes used are part of the package.

Classes:

AuthTools_Acl_Access (interface)

AuthTools_Acl_DbAccess (interface) independent of AuthTools_Acl_Access
AuthTools_Acl_DbAccessAuto uses AuthTools_DBGateway

Note: Both AuthTools_Acl_FileAccess and AuthTools_Acl_XmlAcccess are optional plugins and probably won't be created for the core authorization package.

AuthTools_Acl (interface or abstract class)

AuthTools_Acl_Role (for Role based authorization)
AuthTools_Acl_RolePositions
  • SITE_OWNER
  • SITE_SUPER_ADMINISTRATOR
  • SITE_ADMIN
  • SITE_SUPER_MODERATOR
  • SITE_MODERATOR
  • SITE_SUPERVISOR
  • SITE_USER
  • SITE_ANONYMOUS
AuthTools_Acl_Level (for Level based Authorization, you never know, people might not need 'advanced' level setting.)

AuthTools_Acl_Permission (for Action Permission based Authorization)

ACL Name Change

I forget what everyone decided that the authorization name would be.

ACL = Access Control List, which I don't think matches the action. I was thinking that Authorization would be better, but it is longer and I didn't want to type it out. I would like to use the ACL name, even if it may be ambiguity.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Personally, I don't remember either, but ACL (or access control list) implies a certain implementation of the concept.

I'm also not big on the idea of a supertype: we shouldn't be enforcing package dependencies: we should be enforcing interface dependencies. Instead of instanceof AuthTools_ACL, it should be instanceof AuthTools_ACL_iAccess, etc.

Hmm... just class names is a little sparse for me. How about interfaces or guts?
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

True. It is the reason why I put it out there. While writing it on paper, I came in a little problem of the pattern. I believe that a MVC type pattern would work best, but I started to design it as a Singleton. I'm going to try to work out how each of the classes and interfaces will work out and figure out the methods and dependencies.

The main classes will be separate of the Database, which is what the AuthTools_Acl_Access is for. To be used with the AuthTools_Acl.

I won't commit any code until I have a basic model down and it has been reviewed. I will need to review other packages to see how they managed it. I'm not impressed with the ones I have looked at so far.

When the authentication classes are commited, I'll have to update the authorization classes to match the design. Well, once it is commited other brighter minds should be able to fix any problems in the design and implementation.

Zend Framework Auth

It appears that the Zend Framework Core developers are going to take the previous Authenication and Authorization proposals for their own interpretation. They also said that they are going to create just an interface or skeleton for others to implement when they do.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

phpGACL (sorry, my bad) implements access control in a very interesting way, you might want to support their implementation.

As with Zend, I noticed that too. We'll want to keep close eyes on the way they move their interface and implementation and loot and steal whatever is good. :-D
I believe that a MVC type pattern would work best, but I started to design it as a Singleton. I'm going to try to work out how each of the classes and interfaces will work out and figure out the methods and dependencies.
That's because Authorization is a happen only once sort of procedure. In a way, Singleton is applicable since there's only one, but I'd let the application decide that.

With regards to MVC, VERY applicable. Notice that authorization and authentication don't really need complex views (the views are mostly static) EXCEPT for administering these things.
Last edited by Ambush Commander on Sat Jul 01, 2006 1:21 am, edited 1 time in total.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

The live code is now up: http://svn.jpsband.org/live/authtools/classes/tests/

Unfortunantely, the hook isn't in place, so this will be out-of-date once someone makes a commit. santosj, the hook?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Sorry about the triple post...

I've completed an analysis of PEAR Auth. Here are the results:

== PEAR_Auth ==

It is quite useful to make comparisons with existing authentication systems,
compare notes, and integrate good aspects. Aspects marked :!: should be
paid attention to.

PEAR's Auth class is essentially a blob super-class.

AUTH() [constructor]
1. Handle options array
2. Start a session
3. Initialize (involves copying stuff)
4. Handle options parameters

START()
1. Read post for login data
2. If logins are allowed and there's no valid session (CHECKAUTH()), call LOGIN()

LOGIN()
1. If username is set, attempt to validate against datasource
2. If valid, call SETAUTH(username) and call the user good-login callback
3. If failed, call user bad-login callback
4. If enabled, draw login form

SETAUTH()
1. :!: Call session_regenerate_id() to prevent session fixation attacks
2. Record IP and Useragent into session
3. Create a challenge key and pass user
4. Set other appropriate env vars into session

CHECKAUTH()
1. If no session data, return false
2. :!: If expired, return false
3. :!: If idled, return false
4. Handle session:
a. Update idle time
b. Check advanced security (if enabled, as it stands, it's poorly implemented)
1. Generate a challenge (oneway path for user)
2. Check for IP change
3. Check for useragent change
4. Check challenge (might be a todo)
5. If gauntlet passed, return true

Interesting side notes:
* It didn't always use callbacks. I wonder why it started?
* While it will automatically login when appropriate, you must call logout() manually
* Offers facilities to change passwords, add/remove users, and list users
* Good distinction between expiration and idle
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

It is good, and I think I'll rip some of the permission attributes for the Permissions class, however some people might not need that advanced of an ACL. Which is why I want to have a role based one and a permission based one. The Role based one will go before the permission based one. The Role says who can access the page and the permission based one says what they can do once they get there.

I will look further into it once I get started. As a side note, I also wanted to provide a way to manage the roles and permissions. Um, the final implementation may make use of both the role and permission as a group.

I think it would be better if the user themselves are able to set the roles dynamically. However, some roles will be predefined without the use of a database table, in case they don't want to manage the roles with an admin page or don't want to have another table for the management.

Should I look into another's code

I don't know, I'm kind of weary looking at someone's elses code for this project since I'll be more inclined to copy their methods and ideas. Not good, if it looks like I copied and paste. I want the prototype to be my own implementation, so that I can compare mine with another's. I also want to take a look at the phpBB 3 permission based permissions.

The View

It is more like:

Code: Select all

AuthTools_Acl_Page::Set($pageName, $role, $policy);
Or something.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

You do your thing. ;-) I haven't done as extensive study in authorization, and undoubtedly it's a bit harder to implement. The crucial thing is to allow different authorization mechanisms to be swappable with a best practice mechanism. (which you have already paid attention to)
I don't know, I'm kind of weary looking at someone's elses code for this project since I'll be more inclined to copy their methods and ideas. Not good, if it looks like I copied and paste. I want the prototype to be my own implementation, so that I can compare mine with another's. I also want to take a look at the phpBB 3 permission based permissions.
Right. It's especially difficult with PEAR classes since they tend to employ these blob god-classes. Go your way.

Erm... I don't exactly understand what you mean by The View?

XHTML enabled browsers can now view notes, for summarizations of discussion so far: http://svn.jpsband.org/live/authtools/docs/notes/
santosj
Forum Contributor
Posts: 157
Joined: Sat Apr 29, 2006 7:06 pm

Post by santosj »

Ambush Commander wrote:Erm... I don't exactly understand what you mean by The View?

XHTML enabled browsers can now view notes, for summarizations of discussion so far: http://svn.jpsband.org/live/authtools/docs/notes/
Well, I want a way to be able to assign a page an ACL in an easy matter. Not all page would require it. It would be at the top and it could also be a function. The point of which is to manually assign the permissions as opposed to dynamically assigning a permissions. Both would be available. On some projects, like a CMS, dynamically getting and setting the pages makes sense. On projects that the developer created theirself, it would make more sense to assign the access manually since they manually made the page.

However, the more features that are added, the increased complexity there will be in developing it. I'll do some generic tests on the 'best' mechanisms and post the code for critique.
Post Reply