t seemed to me, your authentication class was just intrinsically bloated, perhaps I just missed the boat and stopped paying attention to early.
How then, according to your definition would you add say CAPTCHA as an additional layer of protection to your authentication system? Also, how would one go about adding or possibly replacing user/pass pairs with email/pass pairs or email/user/pass pairs???
How would you utilize your plugin approach to offer 'remember me' functionality?
Ah, that's a good question. These two very common "features" (I hate to call them even that: they should be in every authentication system) are extremely good cases of why all the abstraction that you call "bloat" is necessary.
The captcha requires an extra authenticator. Your basic login would have a PasswordAuthenticator and a CaptchaThrottleAuthenticator. The Password authenticator does the easy stuff with passwords. The throttle authenticator always passes unless a certain condition (usually three logins in an hour or something) is met, then the captcha also has to be authenticated.
The remember me is a little trickier: it's essentially a background process that triggers when 1. the user isn't logged in and 2. the user presents a remember cookie-token and, when successful, results in a new authenticated session. Since it's background, there's no GET parameter that explicitly triggers it, therefore, it can't be implemented as a command. In my system, I would envision it as a hook that attaches to the "post-resume-session: no session" event. It then interfaces with the cookies to determine whether or not a new session can be started, and if it can, overloads the Authentication object with a new objection pending initialization.
With the proper structure in place, none of these functions need modification to the core code. The simplistic version is just that: simplistic. It lacks the necessary plug points and would end up being modded with a big conditional that performs the extra actions (assuming, of course, that you factored out the start session logic).
Last from Zend on ACL was whether it should be split between Authentication and Authorisation, or just be bundled as one - I recall a similar discussion in these parts in the past Smile. That was yesterday unless my mail has fried all the dates again...
Yep, but actually it was fairly quickly agreed that they should be split but closely communicate with each other (my reference thread is
viewtopic.php?t=48544)
I think they simply were not good enough. One was a clone of LiveUser and the others just missed the mark. Honestly, three of the hardest things to design are Authentication, MVC and O/RM. Zend is, probably wisely, waiting until they get lots of discussion and the right proposal before doing anything on those three fronts.
Perhaps. But that doesn't help me very much right now.
