Page 13 of 20

Posted: Thu May 25, 2006 10:10 pm
by Christopher
Ambush Commander wrote:Now... we need some replacement words.
We may not need to because I think we are talking about two slightly different things. I'm talking about the base classes and your are talking about and implementation's classes. By my thinking this library only provides the Authenticator. The application needs to provide adapters to the credentials and datasource actually in the application -- but using our interface and conventions so the Authenticator can deal with them. I think the Authenticator may be very simple. It is the conventions that will make the whole thing work.

Authentication asks two questions:
1. Is this person really who he says it is? (my def) which is a subset of ** An implementation to check user accounts **
2. Is the data/credential valid/genuine? (Arborint's def) ** the raw functionality of the Authenticator **

Credential means two things:
1. A piece of information that establishes the identity of a user (my def) which is a subset of ** An implementation of a user account credential **
2. A piece of information that establishes confidence in a certain assertion (Arborint's def) ** the raw functionality of the Credential Adapter **

So I don't think we are talking about cross purposes
Ambush Commander wrote:Edit 2 - Hey, would you mind going on IRC for a little bit to chat this out a bit and figure it out?
As Burrito found out recently I don't IRC ... sort of my line in the sand to allow me to get some work done.

Posted: Thu May 25, 2006 10:11 pm
by RobertGonzalez
Hey AC, what if you decide what route to go in terms of defining the language to use and we can vote on that? I am of the same general outlook as you are in terms of Authentication and Authorization (as I mentioned in my epiphany post about Costco). However, if there is going to be confusion this early on among a small group of somewhat seasoned developers, imagine how this will come across to a new or less veteran developers that are trying to understand the app they are using.

You are kind of in the driver seat on this one. I am all for letting you take the lead and providing feedback to that as we move forward.

EDIT | ...
NOTE TO SELF: Speed up your keying!

I like what you said too arborint. I like the distinction.

Posted: Thu May 25, 2006 10:26 pm
by Ambush Commander
I think I'm going to have to drop the ball on you guys this time. I can't spend this much time trying to understand the problem... I've also got more urgent things to do. Sorry... I'm clueless. I'll come back a little later, right now, I need a break.

Posted: Thu May 25, 2006 10:31 pm
by Christopher
Everah wrote:You are kind of in the driver seat on this one. I am all for letting you take the lead and providing feedback to that as we move forward.
I agree ... we have covered the necessary ground to a misery inducing level of detail ... time for AC to code ...

Posted: Fri May 26, 2006 3:16 am
by santosj
Well, once we see code we can edit it and then prove our points when we try to implement the other features.

Posted: Fri May 26, 2006 3:09 pm
by Ambush Commander
I've set up a private Subversion repository: http://svn.jpsband.org/authtools/

PM me with a username and password for write-access.

No code yet.
the raw functionality of the Authenticator
The way I understand it, this has several implications:

1. We will need multiple authenticators
2. We need to somehow tranform a valid/genuine credential into a statement about the user's identity (who they say it is) if there are cases in which a valid credential does not necessarily entail the user is who they say they are.

Posted: Fri May 26, 2006 4:15 pm
by santosj
Ambush Commander wrote:I've set up a private Subversion repository: http://svn.jpsband.org/authtools/

PM me with a username and password for write-access.

No code yet.
the raw functionality of the Authenticator
The way I understand it, this has several implications:

1. We will need multiple authenticators
2. We need to somehow tranform a valid/genuine credential into a statement about the user's identity (who they say it is) if there are cases in which a valid credential does not necessarily entail the user is who they say they are.
Dude! Are you using Dreamhost?

Yeah, it would be cool to have write access, but with all of the intelligent people already on this topic I don't think there would be a place for me.

Posted: Fri May 26, 2006 4:18 pm
by Ambush Commander
Dude! Are you using Dreamhost?
Yes. :-D
Yeah, it would be cool to have write access, but with all of the intelligent people already on this topic I don't think there would be a place for me.
PM me anyway. :-)

Posted: Sat May 27, 2006 8:36 pm
by Ambush Commander
Abstract DB wrapper class is now complete.

* Code
* Unit tests

Preferred method is to check-out the code and run it yourself. Ask me if you need help setting up SimpleTest (you'll need to use the alpha)

Posted: Sun May 28, 2006 7:33 pm
by Ambush Commander
Most of the DB stuff has been written, the most interesting feature is the automatic detection that will help the toolkit work out of the box. I am now going to tackle AuthenticationManager.

Posted: Tue May 30, 2006 9:34 am
by Ambush Commander
I think it would be helpful if I delegated modules to other people, who would write code for them, then we'd compare notes and integrate it with the rest of the system. Any takers?

Posted: Tue May 30, 2006 10:57 am
by santosj
I'm not too excited about the DB system, it is a work of art, but I think it is a little bit more complex than it needs to be.

I would need a list of modules you need done. Some things are out of my skill level such as captcha, but I'm willing to do other stuff. I did have some ideas for ACL interface or class.
Ambush Commander wrote:I think it would be helpful if I delegated modules to other people, who would write code for them, then we'd compare notes and integrate it with the rest of the system. Any takers?
They could create a branch and you could merge them or the one that you liked.

Posted: Tue May 30, 2006 11:24 am
by Ambush Commander
I'm not too excited about the DB system, it is a work of art, but I think it is a little bit more complex than it needs to be.
My mode of thinking is as long as externally it seems simple, it's okay. After all, just check the unit tests:

Code: Select all

$database = new AuthTools_DB_MySQL_Auto();
        $result = $database->execute('SELECT 2 + 2');
        $raw = $result->next();
        $this->assertEqual('4', $raw[0]);
The indirection adds complexity, but besides that, there's no convenience functions to cause more troubles. The interface is simple enough where an adapter would be quite easy to write. At least, that's what I hope.
I would need a list of modules you need done. Some things are out of my skill level such as captcha, but I'm willing to do other stuff. I did have some ideas for ACL interface or class.
Hmm... you can do that then. Write an AuthorizationManager interface. We won't deal with the knotty implementation issues, since we haven't actually done much discussion, but we need to add a few trivial authorization managers (such as the authentication=authorization idea) so that the whole thing can work out of the box.

Oh! That brings a naming convention issue: should we name interfaces/abstract classes like iAuthorizationManager? Interface/AuthorizationManager? Or just AuthorizationManager is an interface for everything (I kind of like that last idea, and that's how the DB class is working.)

Posted: Tue May 30, 2006 1:25 pm
by santosj
Ambush Commander wrote: My mode of thinking is as long as externally it seems simple, it's okay. After all, just check the unit tests:

Code: Select all

$database = new AuthTools_DB_MySQL_Auto();
        $result = $database->execute('SELECT 2 + 2');
        $raw = $result->next();
        $this->assertEqual('4', $raw[0]);
The indirection adds complexity, but besides that, there's no convenience functions to cause more troubles. The interface is simple enough where an adapter would be quite easy to write. At least, that's what I hope.
I looked at that and thought that if it implemented SPL iterator it would be better since you would be able to use it in a foreach loop. However I fail to understand why it would be needed since you will most likely be only looking for true or false statements. Unless $result->next() fetches the row, then it should be named fetch() and not next() as when I read next(), I believe that I will be able to iterate over all the returned rows and that isn't possible. Or maybe it does, I think I remember reading that mysql_fetch_row() will iterate over all of the returned rows.

Code: Select all

$raw = $result->next();
$this->assertEqual('4', $raw[0]);
$raw2 = $result->next(); // Will this equal the same $raw or will it return the next row?
ACL

I'll draw something up in the next few days in the branches under santosj/ACL. I have yet to create the folder and will do so when I start the coding. I've found that the empty folders won't be added until there is a file in them.

Posted: Tue May 30, 2006 1:29 pm
by Ambush Commander
I looked at that and thought that if it implemented SPL iterator it would be better since you would be able to use it in a foreach loop.
You're invited to implement SPL for the DB result set. :-) Just make sure you update the unit tests accordingly.

The method is named next() because... well, I really don't know why. It implies iteration. Sort of. Maybe fetch() is more appropriate.
I'll draw something up in the next few days in the branches under santosj/ACL. I have yet to create the folder and will do so when I start the coding. I've found that the empty folders won't be added until there is a file in them.
Actually, empty folders can be added... and since there's really no collisions right now or working copies to break, I request that you do the development in the trunk. (so that I can see the changes, really. :-)