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
Ok ... let me condense it down a little. I think you show three use cases there:
1. Anonymous user making requests to the site an is allowed access. It seems like there are two scenarios here. One is that there is not Access Control code included, either hard coded or a controller decision. Two is that there is Access Control code included, but the Access Control system return "authenticated" because no Access Control data/code has been provided. If we think about the Access Control Controller in its most basic configuration could be set to either Allow All and Deny All.
2. Anonymous user making requests to the site an is denied access. There must be Access Control code present. The system now needs to get the user to some Authentication code. I think the choices here are Redirect or Forward -- we should probably support both.
3. Anonymous or Authenticated user requests to sign-off. The Access Control system need to clear data/code if it exists. I think we also have the choices of Redirect or Forward and should support both.
We also should start to agree on some terms. Tedious but necessary What do people prefer sign-in/out, sign-on/off, log-in/out, log-on/off? What do other systems use? Is there a standard? I checked PEAR::Auth and PHPGACL and both use "login."
1. Anonymous user making requests to the site an is allowed access. It seems like there are two scenarios here. One is that there is not Access Control code included, either hard coded or a controller decision. Two is that there is Access Control code included, but the Access Control system return "authenticated" because no Access Control data/code has been provided. If we think about the Access Control Controller in its most basic configuration could be set to either Allow All and Deny All.
2. Anonymous user making requests to the site an is denied access. There must be Access Control code present. The system now needs to get the user to some Authentication code. I think the choices here are Redirect or Forward -- we should probably support both.
3. Anonymous or Authenticated user requests to sign-off. The Access Control system need to clear data/code if it exists. I think we also have the choices of Redirect or Forward and should support both.
We also should start to agree on some terms. Tedious but necessary What do people prefer sign-in/out, sign-on/off, log-in/out, log-on/off? What do other systems use? Is there a standard? I checked PEAR::Auth and PHPGACL and both use "login."
(#10850)
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
I think login/logout is appropriate.
After reading the progression of this thread, what if the entire thing was built around a single default user 'Anonymous' who has rights to nothing? Since there is a determination made initially as to the users id and rights associated with the id, what if we established that each unique user to the site can be identified as 'Anonymous' with a user id of say, 0. The uniqueness of the user would be determined by their session id or some other 'to-be-determined' unique identifier.
From that point the protocol would be to treat 'Anonymous' as a common user until such time as the user initiates a new identity check by either logging in (initiating a new authentication) or revisiting the currently established authenticated session (remember me).
This may be overgeneralizing what we are hoping to achieve, but I think that a constant state of user tracking would not add a significant amount of overhead and could easily be applied without condition for all users.
Any thoughts?
After reading the progression of this thread, what if the entire thing was built around a single default user 'Anonymous' who has rights to nothing? Since there is a determination made initially as to the users id and rights associated with the id, what if we established that each unique user to the site can be identified as 'Anonymous' with a user id of say, 0. The uniqueness of the user would be determined by their session id or some other 'to-be-determined' unique identifier.
From that point the protocol would be to treat 'Anonymous' as a common user until such time as the user initiates a new identity check by either logging in (initiating a new authentication) or revisiting the currently established authenticated session (remember me).
This may be overgeneralizing what we are hoping to achieve, but I think that a constant state of user tracking would not add a significant amount of overhead and could easily be applied without condition for all users.
Any thoughts?
Hi... I noticed someone mentioned CAPTCHA and thought I'd better stick my $0.02 in.
I have disliked captcha now for some time since it restricts access to your site to those using standard browsers.
What about blind people with screen readers?
A better way to prevent bots would be some sort of logic test or fill in the gaps test.
i.e. The quick brown ___ jumped over the lazey dog. OR What colour is the sky?
Obviously a selection of tests where one can be picked at random but you get the idea.
I have disliked captcha now for some time since it restricts access to your site to those using standard browsers.
What about blind people with screen readers?
A better way to prevent bots would be some sort of logic test or fill in the gaps test.
i.e. The quick brown ___ jumped over the lazey dog. OR What colour is the sky?
Obviously a selection of tests where one can be picked at random but you get the idea.
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
I know hotmail provide their captchas in audio form. Problem is, they are too easy to evade because I bot could be wrtitten to OCR a captcha farily easily (yeah they're getting tougher I know).Everah wrote:CAPTCHA checks can be developed for visual or audio checks, so screen readers or other non-standard browsers still have a chance to pass through. At least I think this is the case.
I like the idea of just having a logic test like that, providing you swicth your questions every months or so it would simply be too random to have a bot answer those for you, and even then they'd need some sort of AI.
EDIT | Sorry I'm aiding in dragging you guys off-topic here... back to the specification eh?
Hi guys.
It seems to me that both aborint and Everah think we should be tracking, or something, anonymous users. Am I missing something? The purpose of doing that, or misunderstanding you two?
- Nathaniel
Log-in/out is fine with me, and it appears to be a "standard", so all the better.aborint wrote:What do people prefer sign-in/out, sign-on/off, log-in/out, log-on/off? What do other systems use? Is there a standard? I checked PEAR::Auth and PHPGACL and both use "login."
It seems to me that both aborint and Everah think we should be tracking, or something, anonymous users. Am I missing something? The purpose of doing that, or misunderstanding you two?
- Nathaniel
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
I was thinking of site-wide authentication. Although I suppose this would probably be a conditional case. Which I guess would make sense. If the authentication application is modular then a developer that is implementing the app can choose to apply it only to certain sections of a site. Unless movement of the user is to be validated/authenticated across the entire access area for a user, in which case the authentication protocol should be applied site-wide.Nathaniel wrote:It seems to me that both aborint and Everah think we should be tracking, or something, anonymous users. Am I missing something? The purpose of doing that, or misunderstanding you two?
Or maybe I am just getting ahead of myself. But it might something we need to consider. If someone uses the authentication app throughout their site and there is no protocol for anonymous users, what is that going to do to their setup?
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Whee. No one actually answered my question ("If the authentication module acts as a controller, but we don't want to pass all of the request context to the module, should we stuff it in parameters or a parameter object"), but that's okay.
On Sessions for Anonymous Users: I never really liked that. Sure, the website my find it convenient to track my progress across the website, but since I have a default "Prompt Me" for any cookies the website wants to set, I will most definitely reject the cookie if it's not necessary. I don't mind anonymous cookies: but they have to do something useful for me besides tracking.
Now, I know for the average Joe user, they're going to have their browsers automatically accepting cookies. And plus, session cookies expire at the end of the session, making them not a part of the "I have too many cookies problem." But I prefer dragging our session feet as long as possible (ideally until the user has logged in).
Obviously, we have to give the implementator a choice.
When it comes to sessions and identifying users, this presents an interesting use-case of Authentication. An anonymous user with a session must prove that he has the access to the same session: but there's no password: all he needs to know is the session ID. Then, when we propagate whether or not the user is authenticated, it's really two states: the user_id, and the user_session. An anonymous user with a session would look like 0 and 2sadf98y3w2r98hae83. You get the point. Both of these two uniquely identify a user, but the user_id has a lot more clout. For mission critical applications, a combination of clever logging could alert the system when there are multiple concurrent sessions for a single user (possible abuse of the system).
I think the problem is a lot clearer when you seperate authorization from authentication.
On terminology - I think login() and logout() are sufficient for our internal representations. Problems with using this terminology is it conflicts with "logging" terminology (we could use "record" though). Also, when it comes down to it, the system chooses whether or not to display "Log in" or "Sign in" on the web page.
On Captcha - In the context of the login, at least, we aren't demanding a Captcha be filled in, rather, three successive tries will require a Captcha to be filled (until a certain time has elapsed). I like this method a lot better then just locking down the account for an hour, but, for someone who can't read the captcha, they can just wait an hour til the account "unlocks"
However, this does pose an important architectural decision: should Captcha implement the interface TuringTest?
Regarding the generation of audio and text input, that is, as Arborint put it, out of our scope. Although I do agree that there is a lack of good Captcha software out there.
Also, logic tests speaking, they must have 1. lots of tests and 2. constant maintenance. Remember: automated bots are fast, so even if they're only able to get 1 out of 40 requests through, that still comes out to a lot.
On Access Control - though I don't use it, I really like phpGACL's system a lot. If we implement an authorization system, I would like to offer several types of authorization, from a very simple admin can only access admin place authorization to a fully fledged authorization system with user groups and roles. So let's not talk about authorization for now, please. The two systems probably can't be divorced, but we must try.
Once again, this stuff is complicated, but is traditionally relegated to the application itself to determine. However, it's still Access Control (hehe).
I just want to caution people against using session IDs to uniquely identify people: they don't: they uniquely identify SESSIONS.
On Sessions for Anonymous Users: I never really liked that. Sure, the website my find it convenient to track my progress across the website, but since I have a default "Prompt Me" for any cookies the website wants to set, I will most definitely reject the cookie if it's not necessary. I don't mind anonymous cookies: but they have to do something useful for me besides tracking.
Now, I know for the average Joe user, they're going to have their browsers automatically accepting cookies. And plus, session cookies expire at the end of the session, making them not a part of the "I have too many cookies problem." But I prefer dragging our session feet as long as possible (ideally until the user has logged in).
Obviously, we have to give the implementator a choice.
When it comes to sessions and identifying users, this presents an interesting use-case of Authentication. An anonymous user with a session must prove that he has the access to the same session: but there's no password: all he needs to know is the session ID. Then, when we propagate whether or not the user is authenticated, it's really two states: the user_id, and the user_session. An anonymous user with a session would look like 0 and 2sadf98y3w2r98hae83. You get the point. Both of these two uniquely identify a user, but the user_id has a lot more clout. For mission critical applications, a combination of clever logging could alert the system when there are multiple concurrent sessions for a single user (possible abuse of the system).
I think the problem is a lot clearer when you seperate authorization from authentication.
On terminology - I think login() and logout() are sufficient for our internal representations. Problems with using this terminology is it conflicts with "logging" terminology (we could use "record" though). Also, when it comes down to it, the system chooses whether or not to display "Log in" or "Sign in" on the web page.
On Captcha - In the context of the login, at least, we aren't demanding a Captcha be filled in, rather, three successive tries will require a Captcha to be filled (until a certain time has elapsed). I like this method a lot better then just locking down the account for an hour, but, for someone who can't read the captcha, they can just wait an hour til the account "unlocks"
However, this does pose an important architectural decision: should Captcha implement the interface TuringTest?
Regarding the generation of audio and text input, that is, as Arborint put it, out of our scope. Although I do agree that there is a lack of good Captcha software out there.
Also, logic tests speaking, they must have 1. lots of tests and 2. constant maintenance. Remember: automated bots are fast, so even if they're only able to get 1 out of 40 requests through, that still comes out to a lot.
On Access Control - though I don't use it, I really like phpGACL's system a lot. If we implement an authorization system, I would like to offer several types of authorization, from a very simple admin can only access admin place authorization to a fully fledged authorization system with user groups and roles. So let's not talk about authorization for now, please. The two systems probably can't be divorced, but we must try.
Okay, this is a bit sketchy on the terminology. Remember: authentication authenticates, while access control authorizes. So I'm a bit confused to see "authenticated" coming from Access Control.Anonymous user making requests to the site an is allowed access. It seems like there are two scenarios here. One is that there is not Access Control code included, either hard coded or a controller decision. Two is that there is Access Control code included, but the Access Control system return "authenticated" because no Access Control data/code has been provided. If we think about the Access Control Controller in its most basic configuration could be set to either Allow All and Deny All.
What if a user is logged in and doesn't have necessary priviledges? Three cases: 1. Flat out Forbidden, 2. User needs to log in, 3. User needs relogin/escalate priviledgesAnonymous user making requests to the site an is denied access. There must be Access Control code present. The system now needs to get the user to some Authentication code. I think the choices here are Redirect or Forward -- we should probably support both.
Once again, this stuff is complicated, but is traditionally relegated to the application itself to determine. However, it's still Access Control (hehe).
By definition, you cannot uniquely identify an anonymous user.After reading the progression of this thread, what if the entire thing was built around a single default user 'Anonymous' who has rights to nothing? Since there is a determination made initially as to the users id and rights associated with the id, what if we established that each unique user to the site can be identified as 'Anonymous' with a user id of say, 0. The uniqueness of the user would be determined by their session id or some other 'to-be-determined' unique identifier.
See my reasons against it above. Of course, we will allow it.This may be overgeneralizing what we are hoping to achieve, but I think that a constant state of user tracking would not add a significant amount of overhead and could easily be applied without condition for all users.
I would think they'd already have that? (checked, it doesn't look like it). Maybe.Well, if the Authenticate class and ACL class are good enough, then you could recommend them for Zend Framework.
Well, that's really the access control's problem. They'd have to default all.Or maybe I am just getting ahead of myself. But it might something we need to consider. If someone uses the authentication app throughout their site and there is no protocol for anonymous users, what is that going to do to their setup?
An application with a front controller or a common include would be able to load the Authentication module every time. Personally, I'd do it, simply so that the skin could always say to the user, "Logged in as User234". Modular authentication, oh ho, I don't think the minimal overhead benefit justifies the added complexity.I was thinking of site-wide authentication. Although I suppose this would probably be a conditional case. Which I guess would make sense. If the authentication application is modular then a developer that is implementing the app can choose to apply it only to certain sections of a site. Unless movement of the user is to be validated/authenticated across the entire access area for a user, in which case the authentication protocol should be applied site-wide.
I would like a Parameter Object, if that is okay with everyone else. The reason why is for me, I would like to extend the Parameter Object, but I that would force me to also extend the Auth class to use the added parameters. I would probably do that anyway.Ambush Commander wrote:Whee. No one actually answered my question ("If the authentication module acts as a controller, but we don't want to pass all of the request context to the module, should we stuff it in parameters or a parameter object"), but that's okay.
Yeah, but wouldn't a Front Controller be complex to the novice user anyway? I think it would be better if you just allow the coder to extend and add to the basic functionality. I'm sure that if enough of the same code is added that it can be placed in the 'base' authentication classes.Ambush Commander wrote:An application with a front controller or a common include would be able to load the Authentication module every time. Personally, I'd do it, simply so that the skin could always say to the user, "Logged in as User234". Modular authentication, oh ho, I don't think the minimal overhead benefit justifies the added complexity.
I think the main reason why people choose to create their own authentication is that everything else is too difficult, too basic, too bloated, or not specific to their individual task.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Too much to comment on ... hopefully we can start to focus soon. 
Captcha - I really don't think it has anything do to with our system. I think the app should supply the both the credential Acquisition code and the Datasource code, so Captcha is no different than checking a any single password system. Whether we provide support or common Acquisition code and the Datasource code is a separate converstation. I think we will need to for testing anyway.
Terminology - login/logout sounds like the choice.
Sessions for Anonymous Users - I really think this decision is up to the app. We need a way to support Allow All or Deny All for Anonymous Users, but I don't think we need to go beyond that.
Access Control - I think the way we disconnect Access Control from Authentication is to provide Access Control with Redirect/Forward capabilities and make it up to the app to send them to the Authentication code.
Context - I'm not sure this is the way to go. I think of it more as a Credentials object. That is essentially the apps data in our format. We will need information on how to handle each credential provided.
Captcha - I really don't think it has anything do to with our system. I think the app should supply the both the credential Acquisition code and the Datasource code, so Captcha is no different than checking a any single password system. Whether we provide support or common Acquisition code and the Datasource code is a separate converstation. I think we will need to for testing anyway.
Terminology - login/logout sounds like the choice.
Sessions for Anonymous Users - I really think this decision is up to the app. We need a way to support Allow All or Deny All for Anonymous Users, but I don't think we need to go beyond that.
Access Control - I think the way we disconnect Access Control from Authentication is to provide Access Control with Redirect/Forward capabilities and make it up to the app to send them to the Authentication code.
Context - I'm not sure this is the way to go. I think of it more as a Credentials object. That is essentially the apps data in our format. We will need information on how to handle each credential provided.
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Wel, the specification is going to get pretty big at this rate.Too much to comment on ... hopefully we can start to focus soon.
Naming, I suppose.I'm not sure this is the way to go. I think of it more as a Credentials object. That is essentially the apps data in our format. We will need information on how to handle each credential provided.
Here's the part of the spec on the credentials:
Code: Select all
\section{Credentials}
Interfacing directly with \verb|$_POST| and friends, however, makes things
difficult for unit testers as well as applications that implement their
own request class. Therefore, we define an authentication context object
(\verb|AuthTools_Credentials|) which we will pass to the controller and the
commands. This context is a subset of what an application wide context
object would supply. Also, note the use of variables rather than getters
and setters. Context is immutable and acts more like a well-defined
structure than an object.
\begin{phpcode}\begin{verbatim}
class AuthTools_Credentials
{
public var $login_username;
public var $login_password;
public var $login_remember_me;
public var $session;
public var $token;
}
\end{verbatim}\end{phpcode}
If the user so decides, we can have the object itself set these parameters.
\begin{phpcode}\begin{verbatim}
class AuthTools_Credentials_Auto extends AuthTools_Credentials
{
private $_magic;
public function __construct() {
$this->_magic = (bool) get_magic_quotes_gpc();
$this->login_username = $this->_getPost('username');
$this->login_password = $this->_getPost('password');
$this->login_remember_me = isset($_POST['remember_me']);
$this->session = new AuthTools_Session();
$this->token = new AuthTools_Token();
}
private function _getPost($key) {
if (!isset($_POST[$key])) return null;
$value = (string) $_POST[$key];
return $this->_magic ? stripslashes($value) : $value;
}
}
\end{verbatim}\end{phpcode}
Something along these lines will be supplied with the framework to let
users start using the authentication code out of the box.Then you're talking about bundling a relatively limited access control module with the authentication module.I really think this decision is up to the app. We need a way to support Allow All or Deny All for Anonymous Users, but I don't think we need to go beyond that.
I'm not sure I understand how authorization has anything to do with forwarding/redirecting...
I think it would be very useful to see some Acceptance/Integration style tests to describe the desired interface to the authentication module. arborint listing of the use cases starts to approach this, but not how it would be used. Not so much the more low level technical details that are being shown in the TeX.
For instance,
The design is poor, but I'm trying to understand the usage of this community effort. If your making the decision to not handle authorization issues, it seems that the only legitimate API is four functions along the lines of
isValidCredentials
isAuthenticated
getUserName
logout (destroyAuthenticator)
aside from the configuration options.
Thus the role of authentication is a plug-able system of testing user credentials and propagating established credentials across the user session. Thus the forwarding/redirecting appears to be out-of-scope -- thats a decision that the application makes in response to the isAuthenticated call. Now there may be some internal redirecting in some of the more sophisticated authenticators in response to a set number of failed attempts, etc.
But the semi-normal method of
a) testing is user authenticated
b) if not redirect to a login page, with a returnTo field set
c) on successful login redirect to original destination
is outside of scope.
For instance,
Code: Select all
// Case 1b
$authenticationSource = new CredentialChecker( new RejectAllAuthenticator() );
$isAuthenticated = $authenticationSource->isUserAuthenticated();
$this->assertFalse($isAuthenticated);
// Case 1a
$authenticationSource = new CredentialChecker( new AllowAllAuthenticator() );
$isAuthenticated = $authenticationSource->isUserAuthenticated();
$this->assertTrue($isAuthenticated);
//Case 2
$username="TestUser";
$correctPassword="A1s2$5";
$incorrectPassword="aaaaaaaa";
$_POST["username"]=$username;
$_POST["password"]=$correctPassword;
$authCredentials = new AuthenticationCredentials($_POST,$_SESSION, $_COOKIE);
$dbAuthentication = new MockMysqlDBAuthenticator($this);
$authenticationSource = new CredentialChecker($dbAuthentication );
$dbAuthentication->expectOnce("isValidCredentials",array($userName,$correctPassword));
$dbAuthentication->return("isValidCredentials",false, array($userName,$correctPassword));
$isAuthenticated = $authenticationSource->isUserAuthenticated($authCredentials);
$this->assertTrue($isAuthenticated);isValidCredentials
isAuthenticated
getUserName
logout (destroyAuthenticator)
aside from the configuration options.
Thus the role of authentication is a plug-able system of testing user credentials and propagating established credentials across the user session. Thus the forwarding/redirecting appears to be out-of-scope -- thats a decision that the application makes in response to the isAuthenticated call. Now there may be some internal redirecting in some of the more sophisticated authenticators in response to a set number of failed attempts, etc.
But the semi-normal method of
a) testing is user authenticated
b) if not redirect to a login page, with a returnTo field set
c) on successful login redirect to original destination
is outside of scope.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
I disagree. The low level technical details are the use case. Besides, I didn't even check to see whether or not it compiles.Not so much the more low level technical details that are being shown in the TeX.
testCredentials(), however, is quite complicated, and it's worth defining how it would be work in an informal manner. Also, you pose another interesting option: does the rest of the application interface with the authenticator itself to determine which user is logged in? Or does the authenticator stash it somewhere else and then destructs (which was what we were thinking before)?it seems that the only legitimate API is
testCredentials
isAuthenticated
getUserName
logout (destroyAuthenticator)
Module to toolset to pattern - Nielsene made me think about what I'm trying to do here. An integrated authentication solution that works out of the box is a module. A bunch of loosely associated parts that can be put together to make a cohesive whole but also can be used seperately is a toolset. But maybe I'm in patterns mode: there's no one fit all solution, the document simply demonstrates the usual patterns in an authentication module.
Maybe I don't understand it very well either. We haven't voted on anything yet.I'm trying to understand the usage of this community effort.
Okay, here's a shot at a use case. It's not written in an integration style though.
Code: Select all
// application now hits authentication phase
$auth_credentials = new Credentials($context); // data: sessions, cookies, post
$auth_actions = new Authentication_Actions($context); // state: logout/login
$auth_controller = new AuthTools_Controller();
$command_chain = $auth_controller->getCommandChain($auth_action, $auth_credentials);
$auth_status = $command_chain->execute();
// stash the status away in a place where everyone can reach
$_SESSION['auth_status'] = $auth_status;
// elsewhere in the application
$authority->authorize($action, $auth_status);
// if not authorized, throws an exception, caught by default exception handler
throw new AuthorizationException_NeedLogin();Agreed that that developer-visible function is where the heart of the module is hidden.Ambush Commander wrote: testCredentials(), however, is quite complicated, and it's worth defining how it would be work in an informal manner. Also, you pose another interesting option: does the rest of the application interface with the authenticator itself to determine which user is logged in? Or does the authenticator stash it somewhere else and then destructs (which was what we were thinking before)?
I think this starts to show why everyone ends up hand-writing their authentication module. Authentication, on the surface is a very small piece of the "security" infrastructure that also includes authorization and logging -- not to mention the related but less coupled issues of log-mining (automated response to attack patterns) and actual user account creation/management. Yes if you build in capcha, etc you've constructed a more robust and significant system, but if its hard to get setup/use it won't receive the usage it deserves.Module to toolset to pattern - Nielsene made me think about what I'm trying to do here. An integrated authentication solution that works out of the box is a module. A bunch of loosely associated parts that can be put together to make a cohesive whole but also can be used seperately is a toolset. But maybe I'm in patterns mode: there's no one fit all solution, the document simply demonstrates the usual patterns in an authentication module.
If your goal is a minimal/clean authenticator that doesn't impact the existing application greatly, then I suspect its going to be a bear to configure and it makes it harder to use in normal usage patterns -- you push a lot of standard "authentication" interactions into the application code. Once you've done this a lot of people will decide its easier to code their own. However if you make a more comprehensive module that automates more of the common tasks (which will probably have to include authorization at least) you start to require significantly more intrusion into both the data model (DB schema or separate flat file) and possible start to place demands on the applications pre-existing Session or User abstractions.
I don't mean to be discouraging, I think this is a great idea, but I do think that more thought needs to be placed into the Plug-and-play versus toolkit type approach or simply "exemplar" code aspect of the effort along with what type of requirements you're comfortable putting onto code that uses your code.
Some questions:Okay, here's a shot at a use case. It's not written in an integration style though.
Code: Select all
// application now hits authentication phase $auth_credentials = new Credentials($context); // data: sessions, cookies, post $auth_actions = new Authentication_Actions($context); // state: logout/login $auth_controller = new AuthTools_Controller(); $command_chain = $auth_controller->getCommandChain($auth_action, $auth_credentials); $auth_status = $command_chain->execute(); // stash the status away in a place where everyone can reach $_SESSION['auth_status'] = $auth_status; // elsewhere in the application $authority->authorize($action, $auth_status); // if not authorized, throws an exception, caught by default exception handler throw new AuthorizationException_NeedLogin();
What is a $context -- I know you've talked about it before. However as shown in this example (probably oversight) it appears to suggest that the $context is some class provided by the Application, not by the AuthenticationModule/Toolkit. Now a context is a rather common requirement in some form of another of all applications and if you require a specific Context for this to work, you've pushed a fairly large requirement to the application from the module.
To me, the Authentication_Credentials is already the parameter object, and it should be instantiated by the application with its needed parameters. You've already shown how its relatively easy to create a useful auto-populating subclass of an interface. If other users need to subclass it differently, then that's easily done. For instance, my Front Controllers grab and cleanse the GET and POST superglobals very early in the execution process. (ie _GET and _POST are copied to class variables and $_GET=array(); $_POST=array(); to enforce all access through specific, known safe channels). I'd have no trouble writing a custom AuthenticationCredentials. As the AuthTools_Controller doesn't use the context, it seems like you can remove that dependency.
What is $authority in your example? Is it one of the classes listed in the first part?
Am I correct to assume that Authentication_Actions is parsing the URL and or GPCS to locate the name of Action you care about (login/logout)?
You are including a commandChain because you want to add pre-filters for checking if a DB is down, or for what other reasons?
If I read some of the early parts of this thread right, this tool is planned for use within Front Controller styled applications, thus wouldn't it be "nicer" to somehow have the "AuthenticationManager" return items to add to the "pre-filter" chain of the front controller as opposed to generating a separate controller (but again this show a place where the module/toolkit issue pops up)