So, your code is dependent on the Auth class as oppose to my example which the Auth class accepts as a plugin. I like my example better since it would be more modular, but from a practical standpoint, your example would be easier.arborint wrote:I was just present that code as an example of the basic form controller logic. There is no authentication code shown and my comment was only that some of those calls would internally need to make use of our auth library. I think that is form code that just about any PHP programmer could follow -- and it does not dictate anything about the acutal presentation of the form. For example, the $form->render() method could use Smarty or TemplateLite or something else.
Authentication Poll & Community Design [PLEASE JOIN!]
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Yes, I think that the Auth code should have no dependencies on any presentation code -- PEAR::Auth does it that way with callbacks. As I have said, I think the application should acquire the credentials (whether username/password or remember me cookie), provide the known datasource (to validate againse), and a persistence mechanism (for session data).santosj wrote:So, your code is dependent on the Auth class as oppose to my example which the Auth class accepts as a plugin. I like my example better since it would be more modular, but from a practical standpoint, your example would be easier.
We can certainly supply some canned presentation code to make building simple login pages easier though.
(#10850)
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
Can we provide a single config file that can be read by the app? That way a user can specify some important information in a single place without having to do anything with the app. Things like telling the app if there is a user form to include (and if not, we can add in a canned one), if they will be using a database or files for user data, etc. That way we can effectively develop the app without the need for a user to do anything inside of it. What do you all think about this idea?
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
I had, as Everah puts it, a slight epiphany while I was taking a walk. The relevation?
There is no way to definitely, 100% authenticate a person.
Which leads to the axiom,
There can be multiple factors used to determine whether or not a person is authenticated.
or
Authentication is not a binary attribute.
Still trying to digest the implications of this revelation.
There is no way to definitely, 100% authenticate a person.
Which leads to the axiom,
There can be multiple factors used to determine whether or not a person is authenticated.
or
Authentication is not a binary attribute.
Still trying to digest the implications of this revelation.
Last edited by Ambush Commander on Sun May 21, 2006 7:53 pm, edited 1 time in total.
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
I had thought of this at a point. My thought was that we can only truly authenticate a user against credentials the user supplied at some point (say during registration). Of course, that may or may not be good enough for a user's app, but the situation does exist that a user may lose, leak or disseminate their information into the publis realm at which point security of that information has been compromised before it ever gets to the app. The app could easily authenticate creditials, but is it really authenticating the user? Do we need to worry about this?Ambush Commander wrote:I had, as Everah puts it, a slight epiphany while I was taking a walk. The revalation?
There is no way to definitely, 100% authenticate a person.
Which leads to the axiom,
There can be multiple factors used to determine whether or not a person is authenticated.
or
Authentication is not a binary attribute.
Still trying to digest the implications of this revelation.
Questions, questions...
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
No, we don't. We're not here to create some revolutionary new 100% fraud-proof authentication method. What we do have to worry about is how the application will "weight" different types of credentials. For a simple use case, any credential will fit, but for more sensitive transactions, the authentication can't be based solely from a remember me (SourceForge does this).My thought was that we can only truly authenticate a user against credentials the user supplied at some point (say during registration). Of course, that may or may not be good enough for a user's app, but the situation does exist that a user may lose, leak or disseminate their information into the publis realm at which point security of that information has been compromised before it ever gets to the app. The app could easily authenticate creditials, but is it really authenticating the user? Do we need to worry about this?
::other replies still pending::
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Here's some replies I promised.
There is no need, however, for the Authentication component to have to do this. Passing everything by parameter, at this point, is still quite feasible.
However, if people insist, we can add another function wrapper that can pass a configuration array. More features.
On the use-case creep - As we add even more and more ways to use the application, it will be difficult to instruct users how to use it at all (Oh, you can use this class in 100 ways). Perhaps we could classify them from most intrusive to least intrusive or something, or perhaps organize them "wizard"-style?

Santosj's code at this post - I finally think I understand it. And that wasn't an easy process. Reflection makes stuff so much harder to use.
Santosj, if we really needed the form to be that configurable, I'm sure the developer would have their own pet form generation system. Plus, I don't see why we couldn't just...
And I've done this before and it's a pain. Sorry, but no.
arborint's code from this post
My previous objection could be circumvented with santosj's suggestion that the raw post data just be serialized and then reinstantiated when the user travels back to the appropriate page. This is, however, out of our scope, because there are security/filesystem implications for things like uploads and passwords (which ideally aren't persisted in plaintext form).
User/password as exceptions
I agree that they shouldn't be exceptions, but for different reasons. Any controller worth its salt should be able to intercept a not authorized/bad login credentials and redirect application flow to the appropriate page. Plus, the thin-ness of application should make it possible to bubble it all the way up without too much problem (the greatest feature of exceptions is the ability to bypass this bubbling).
Yes, all replies done!
My responses in bold. Here's my assertion: configuration files, in there essence, are global pieces of information. Globals are usually frowned upon, because it's difficult to track what's going on with them, but are quite useful when a particular parameter needs to be passed several levels deep and you don't want to bubble it through parameters.Can we provide a single config file that can be read by the app? No. But not for the reasons you put forth. That way a user can specify some important information in a single place without having to do anything with the app. Things like telling the app if there is a user form to include (and if not, we can add in a canned one), if they will be using a database or files for user data, etc. That way we can effectively develop the app without the need for a user to do anything inside of it. They shouldn't need to do any edits. But you don't need a configuration file. What do you all think about this idea?
There is no need, however, for the Authentication component to have to do this. Passing everything by parameter, at this point, is still quite feasible.
However, if people insist, we can add another function wrapper that can pass a configuration array. More features.
On the use-case creep - As we add even more and more ways to use the application, it will be difficult to instruct users how to use it at all (Oh, you can use this class in 100 ways). Perhaps we could classify them from most intrusive to least intrusive or something, or perhaps organize them "wizard"-style?
So you force it the other way: the auth code is not dependent on presentation, the presentation is dependant on Auth code! That is, the presentation has to know about how to get info from the auth code, even if it's through some mediating wrapper. We could bundle a Smarty extension with our app to facilitate login form generation.Yes, I think that the Auth code should have no dependencies on any presentation code -- PEAR::Auth does it that way with callbacks.
Agreed, but the auth module also needs to be able to autodetect this stuff.As I have said, I think the application should acquire the credentials (whether username/password or remember me cookie), provide the known datasource (to validate againse), and a persistence mechanism (for session data).
Some of the most spectacular extra features (notably challenge/response and RSA encryption) will require a substantial bit of client-side work. Then the canned presentation code becomes a must.We can certainly supply some canned presentation code to make building simple login pages easier though.
Try not to get too attached to SPL. Not everyone knows what they are. (I do know what they are but have never used them)Also, I'm trying to think of a good excuse to use SPL Observer
Santosj's code at this post - I finally think I understand it. And that wasn't an easy process. Reflection makes stuff so much harder to use.
Santosj, if we really needed the form to be that configurable, I'm sure the developer would have their own pet form generation system. Plus, I don't see why we couldn't just...
Code: Select all
$authform->paintStart('confirm.php');
$authform->paintUsername();
$authform->paintPassword();
$authform->paintEnd();arborint's code from this post
My previous objection could be circumvented with santosj's suggestion that the raw post data just be serialized and then reinstantiated when the user travels back to the appropriate page. This is, however, out of our scope, because there are security/filesystem implications for things like uploads and passwords (which ideally aren't persisted in plaintext form).
No, but that use code shows us what the API looks like.The code is awesome. Do you have down what all of the classes are at this point?
User/password as exceptions
I agree that they shouldn't be exceptions, but for different reasons. Any controller worth its salt should be able to intercept a not authorized/bad login credentials and redirect application flow to the appropriate page. Plus, the thin-ness of application should make it possible to bubble it all the way up without too much problem (the greatest feature of exceptions is the ability to bypass this bubbling).
I'd like to hear a reply some time or another, because I'm going to be augmenting that code pretty soon.I need a little time to think about the code you posted.
Correct. We're not dealing with htaccess.Htaccess does everything in and of itself
That's another way to get credentials, and it's probably the way to manage authentication for a user who doesn't accept cookies.HTTP basic authentication.
Yes, all replies done!
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Oh, by the way, we're using SimpleTest, right?
Another random point http://www.xml.com/pub/a/2003/12/17/dive.html is another interesting way to handle the no-SSL problem.
Java, of course, has their own authentication/authorization framework. JAAS. Read more: http://java.sun.com/j2se/1.4.2/docs/gui ... nOnly.html http://java.sun.com/j2se/1.4.2/docs/gui ... e.html#Who
Another feature! - Single Signon!
Another random point http://www.xml.com/pub/a/2003/12/17/dive.html is another interesting way to handle the no-SSL problem.
Java, of course, has their own authentication/authorization framework. JAAS. Read more: http://java.sun.com/j2se/1.4.2/docs/gui ... nOnly.html http://java.sun.com/j2se/1.4.2/docs/gui ... e.html#Who
Another feature! - Single Signon!
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I really can't keep up with all this info so I will only respond to direct suff. I think there is a huge difference between the the two dependencies -- if the auth code is dependent on the presentation we have no way of guaranteeing that it works. If the presentation (i.e. the app) is dependent on the auth code then we can create modular, testable units.Ambush Commander wrote:So you force it the other way: the auth code is not dependent on presentation, the presentation is dependant on Auth code! That is, the presentation has to know about how to get info from the auth code, even if it's through some mediating wrapper. We could bundle a Smarty extension with our app to facilitate login form generation.
I'm not sure what you mean by "autodetect"? Please explain. If you mean that if a plugin feature is installed (e.g. remember me) then the system uses it -- then we are in agreement.Ambush Commander wrote:Agreed, but the auth module also needs to be able to autodetect this stuff.As I have said, I think the application should acquire the credentials (whether username/password or remember me cookie), provide the known datasource (to validate againse), and a persistence mechanism (for session data).
Some of the most spectacular extra features (notably challenge/response and RSA encryption) will require a substantial bit of client-side work. Then the canned presentation code becomes a must.We can certainly supply some canned presentation code to make building simple login pages easier though.
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Hahaha... at some point I'll have a nervous breakdown and then we'll have eight+ pages worth of discussion that no one will be able to understand. I'd still like to request (if you didn't see my other request) that you comment some time or another on the authtools_quick_authenticate() function.I really can't keep up with all this info so I will only respond to direct suff.
I didn't say I was against it.I think there is a huge difference between the the two dependencies -- if the auth code is dependent on the presentation we have no way of guaranteeing that it works. If the presentation (i.e. the app) is dependent on the auth code then we can create modular, testable units.
It means different things for each type, but in general, it's the automatic instantiation of packaged wrappers for the most common solutions out there. For datasource, it counts as a MySQL DB class that uses the default table and column names and depends on mysql_*'s cached resource. For persistence mechanism/session data it depends on the default session cookie name and a custom entry for itself in the $_SESSION array. For request, I already demonstrated AuthTools_Credentials_Auto. That's autodetection.I'm not sure what you mean by "autodetect"?
Even remember me could be auto-detected, even though we have agreed that it is a plugin. Maybe we should also have an AuthTools_Controller_Full which loads all plugins... Hmmm... Plugins cause interesting packaging problems. What about installing new packages? I'd rather have all the code just sitting around, ready to be used, but not parsed/included.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I think it might be a good idea at this point to focus on one thing at at time after the last five page ideafest! That sound like a good place to start. Can you repost itAmbush Commander wrote:I'd still like to request (if you didn't see my other request) that you comment some time or another on the authtools_quick_authenticate() function.
I think I would prefer an explicit system that only did what I told it to, but I don't think your auto-detect and my manual stuff are exclusive. I think the core should be manual and automatic wrappers can be placed around it with reasonable defaults and conventions -- I think that makes a lot of sense. I guess I am more focused on the simplest core right now.Ambush Commander wrote:It means different things for each type, but in general, it's the automatic instantiation of packaged wrappers for the most common solutions out there. For datasource, it counts as a MySQL DB class that uses the default table and column names and depends on mysql_*'s cached resource. For persistence mechanism/session data it depends on the default session cookie name and a custom entry for itself in the $_SESSION array. For request, I already demonstrated AuthTools_Credentials_Auto. That's autodetection.I'm not sure what you mean by "autodetect"?
Even remember me could be auto-detected, even though we have agreed that it is a plugin. Maybe we should also have an AuthTools_Controller_Full which loads all plugins... Hmmm... Plugins cause interesting packaging problems. What about installing new packages? I'd rather have all the code just sitting around, ready to be used, but not parsed/included.
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Exactly!I think I would prefer an explicit system that only did what I told it to, but I don't think your auto-detect and my manual stuff are exclusive. I think the core should be manual and automatic wrappers can be placed around it with reasonable defaults and conventions -- I think that makes a lot of sense. I guess I am more focused on the simplest core right now.
So... let's focus on authtools_quick_authorize()! (reposted here as a reminder) (your comment really didn't jive with the quote, so I'm assuming that you endorse this?)I think it might be a good idea at this point to focus on one thing at at time after the last five page ideafest! That sound like a good place to start.
Code: Select all
// if user authenticates, use user is authorized
function authtools_quick_authorize($continue_execution = false)
{
$credentials = new AuthTools_Credentials_Auto();
$controller = new AuthTools_Controller();
$command_chain = $controller->getCommandChain($credentials);
// Command chain works this way:
// Depending on the credentials, multiple actions could be going on.
// if a user has a session and a remember me token, both commands get
// added to the chain. The application first tries to resume the
// session: if that fails, it then tries to create a new session from
// the remember me token. Otherwise, a failed session could preclude a
// user from redeeming their remember me token.
$command_chain->executeCommands();
$auth_status = $command_chain->getAuthenticationStatus();
$is_authenticated = $auth_status->isAuthenticated();
$is_authorized = $is_authenticated; // is_authenticated is equivalent to is_authorized
if ($continue_execution) {
return $is_authorized;
}
if (!$is_authorized) {
$form = new AuthTools_BasicForm($auth_status);
echo $form->getContents();
exit;
}
return true; //user is authorized
}- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Here is my take on how it would work:
I don't deal with where $adapterObjectForMyUserDatabase and $adapterObjectForMySessionSystem come from in this example .
Code: Select all
// if user authenticates, use user is authorized
function authtools_quick_authorize($continue_execution = false)
{
$controller = new AuthTools_AuthController();
// give the credentials to the auth controller
$credentials = new AuthTools_Credentials_Auto();
$controller->setCredentials($credentials );
// likewise we need some to check the credentials against
$controller->setDatasourceGateway($adapterObjectForMyUserDatabase);
$is_authenticated = $controller->isAuthenticated();
// $is_authorized != $is_authenticated because authenticated only
// means that the credentials given match those in the known datasource.
// Some kind of user data (group, role, permissions, etc.) would
// need to be given to the Access Control system (not included
// here) in order for the request to be authorized
if (!$is_authenticated ) {
$form = new AuthTools_BasicForm($auth_status);
echo $form->getContents();
exit;
} else {
// now we need to register this account with the Access Control system
$access = new AuthTools_AccessController();
// we need some session support
$access->setPersistenceGateway($adapterObjectForMySessionSystem);
// finally give the access controller the data it needs to allow/deny access
// for this authenticated session
$access->register($adapterObjectForMyUserDatabase);
}
return true; //user is authenticated
}
Last edited by Christopher on Sun May 21, 2006 10:13 pm, edited 1 time in total.
(#10850)
It is possible to detect the existance of whether of predefined class exists or not. We just have to specify how we are going to handle the 'plugable' classes. Do we want or need to have plugable classes? I believe that other developers would be able to get into the system more if they knew it was a simple process to add new elements.Ambush Commander wrote: Even remember me could be auto-detected, even though we have agreed that it is a plugin. Maybe we should also have an AuthTools_Controller_Full which loads all plugins... Hmmm... Plugins cause interesting packaging problems. What about installing new packages? I'd rather have all the code just sitting around, ready to be used, but not parsed/included.
That is what I was trying to get across with the AuthForm code. If you wanted to use it, you just plug it in. If you don't want to use it, then there is not a need to do so. I like the idea of plugin code as it gives me even more control. I could use the other dependent classes of the main Auth class to create my own implementation or extend the original class (which is sort of the same thing).
It would be longer but the Auto class is possible along with the manual one, or any one inbetween. We could create both or many classes and reference the one that the developer will most likely need.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US