Page 2 of 2
Posted: Wed Sep 20, 2006 10:11 pm
by Christopher
Hockey wrote:I'm pretty sure I've seen Arborint on there voicing his concerns about the authentication systems already proposed...
No, I don't believe I was.
The Zend Framework has an ACL proposal and they are working on an Authentication base, so I am sure it will be well covered.
Posted: Wed Sep 20, 2006 10:13 pm
by Ambush Commander
Perhaps Zend will win out in the end. A version 0.1.5 developer's preview, however, is certainly not a framework that will dominate the PHP world. It has potential, but one has to work with what you're given. Going Zend will require a lot more upfront maintenance cost as the APIs shift around and the framework is actively developed.
As for authentication plain vs. feature-rich, I don't think developers should settle for plain authentication: it can be a made a lot more secure by not transmitting plaintext password over the wire (challenge/response or encryption), enforcing server-side password hashing that is forwards-compatible, etc. A library, for me anyway, is supposed to take care of the details and let the developer focus on other things. A modular library lets the developer pick which parts of the application he wants to have control over and leaves the other parts still working. Perhaps you want to swap out the backend to LDAP but keep the gnarly JavaScript security enhancements for the form. Plugins are not so much seperate things but maintained segments of the application that simply can be turned off for simplicity or speed.
That's my philosophy, anyway. And that's why I think plugins make a lot of sense.
Anyway, in the end, life is simple. A framework either has authentication, or doesn't have authentication.
Posted: Wed Sep 20, 2006 10:35 pm
by alex.barylski
arborint wrote:Hockey wrote:I'm pretty sure I've seen Arborint on there voicing his concerns about the authentication systems already proposed...
No, I don't believe I was.
The Zend Framework has an ACL proposal and they are working on an Authentication base, so I am sure it will be well covered.
Hmmm sorry man...

I thought you were part of the panel, I seen a fellow named Christopher Thompson and assumed it was you
My bad...
Posted: Wed Sep 20, 2006 10:48 pm
by alex.barylski
Ambush Commander wrote:Perhaps Zend will win out in the end. A version 0.1.5 developer's preview, however, is certainly not a framework that will dominate the PHP world. It has potential, but one has to work with what you're given. Going Zend will require a lot more upfront maintenance cost as the APIs shift around and the framework is actively developed.
As for authentication plain vs. feature-rich, I don't think developers should settle for plain authentication: it can be a made a lot more secure by not transmitting plaintext password over the wire (challenge/response or encryption), enforcing server-side password hashing that is forwards-compatible, etc. A library, for me anyway, is supposed to take care of the details and let the developer focus on other things. A modular library lets the developer pick which parts of the application he wants to have control over and leaves the other parts still working. Perhaps you want to swap out the backend to LDAP but keep the gnarly JavaScript security enhancements for the form. Plugins are not so much seperate things but maintained segments of the application that simply can be turned off for simplicity or speed.
That's my philosophy, anyway. And that's why I think plugins make a lot of sense.
Anyway, in the end, life is simple. A framework either has authentication, or doesn't have authentication.
Fare enough, personally a good library is one that doesn't demand anythng from me, lets me grow with it not fight against it. The minute I spend more time counter attacking with work arounds, etc I start looking else where. It's why I've hated using anything like FORM generators or CMA applications as frameworks. IMHO at that point their aren't frameworks, but application skeletons.
Authentication should be a simple process and perhaps could be wound up into a simple class. I have some ideas I've been working on for a couple years. My biggest problem is that so many have way to many features outside the scope of authentication. As an OOP zealot modularity and reuse is absolutely vital to anythings success
Objects (aka; library components) should be drop in and should only communicate *not* intergrate (my own little rythme, you like that one?

) with each other.
Objects, in my previous experience don't offer plugin support, perhaps thats old in thinking, but I've seen very few objects in C++ which have such a thing, which is why i'm confused maybe...
Objects either derive/extend each other or occasionally use a callback instead of overriding/overloading inorder to manipulate the functionality somewhat. Admittedly I have very little knowledge of how you or d11 use plugin architecture in your classes/projects, I've been wanting to ask how you use them and how they fit into the entire scheme of things, so I guess now is a good time???
AC or d11 would you mind explainging how these plugins extend your classes? I may steal ideas for my own codebases in the future
Cheers

Posted: Thu Sep 21, 2006 12:18 am
by Christopher
Hockey wrote:Hmmm sorry man...

I thought you were part of the panel, I seen a fellow named Christopher Thompson and assumed it was you

That would be me ... I just don't recall voicing concerns about the authentication systems ... I may have commented about proposals though.
Posted: Thu Sep 21, 2006 12:23 am
by alex.barylski
arborint wrote:Hockey wrote:Hmmm sorry man...

I thought you were part of the panel, I seen a fellow named Christopher Thompson and assumed it was you

That would be me ... I just don't recall voicing concerns about the authentication systems ... I may have commented about proposals though.
Hmmmm...perhaps I misinterpreted or mixed you with someone else...I dunno
I recall you voicing an argument or concern about DI in one of the authentication proposals??? Or it could be someone else...admittedly I haven't looked at Zend in about a month so my recall could and likely is choppy
Total Recall...what a cool movie

Posted: Thu Sep 21, 2006 9:30 pm
by Ambush Commander
Well a plugin, very loosely defined, allows run-time swapping of an implementations. PHP makes this very easy to do, and there's no doubt you're already using some sort of plugin pattern without even knowing it.
The trick, however, is to make the right "plug points" so that it's easy for an end-developer to swap whatever part he needs without being to blunt: for example, if I need to replace a wheel but the only way to do that is to yank off the entire axle system, that's not a very good plug point.
It also relates to coding to an *interface* not an *implementation*.
I'm interested in a summary of the proposed authentication systems and why they failed. Any pointers?
Posted: Thu Sep 21, 2006 11:48 pm
by alex.barylski
Ambush Commander wrote:Well a plugin, very loosely defined, allows run-time swapping of an implementations. PHP makes this very easy to do, and there's no doubt you're already using some sort of plugin pattern without even knowing it.
The trick, however, is to make the right "plug points" so that it's easy for an end-developer to swap whatever part he needs without being to blunt: for example, if I need to replace a wheel but the only way to do that is to yank off the entire axle system, that's not a very good plug point.
It also relates to coding to an *interface* not an *implementation*.
I'm interested in a summary of the proposed authentication systems and why they failed. Any pointers?
I have probably used a plugin approach as you have suggested just named it something else.
Callbacks, Drivers, Adapters, Abstraction layers, etc...are all techniques/approaches I have used to offer this kind of functionality. What I wanted though, was a trivial example
It 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?
I'm not entirely sure why the Zend authentication proposals failed...I do recall arborint (again I could be wrong) commenting (not voicing his concerns

) about one library possibly not following OOD principles by breaking DIP *I think* atleast what I remember and I'm to lazy to check up on it now (all day I struggled with getting Linux installed and running), ask him, he'd obviously know better if he was indeed the one commenting under the context I suggest.
Anyways, I'd be interested in seeing how you answer the questions I pose for you, see how they differ from my own implementions, etc...
Cheers

Posted: Fri Sep 22, 2006 2:37 am
by Christopher
Ambush Commander wrote:I'm interested in a summary of the proposed authentication systems and why they failed. Any pointers?
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.
Posted: Fri Sep 22, 2006 3:05 am
by Maugrim_The_Reaper
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

. That was yesterday unless my mail has fried all the dates again...
Posted: Fri Sep 22, 2006 6:28 pm
by Ambush Commander
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.
