Page 1 of 20

Authentication Poll & Community Design [PLEASE JOIN!]

Posted: Tue May 16, 2006 3:46 pm
by Ambush Commander
Short and quick. Maybe some reasons why things have ended up this way are nice. (yes, it's that time of the year again. The first two times I built an authentication system, things were painful, and I'm not so keen on repeating the experience, but from what I see, most prewritten classes are dreadfully deficient or clunky).

Other topics (a bit recent too, but I didn't feel like reviving dead threads):
* viewtopic.php?t=47735
* viewtopic.php?t=47407

Subversion repository: http://svn.jpsband.org/authtools/

Posted: Tue May 16, 2006 4:00 pm
by Burrito
99.9% of my stuff is homegrown.

I think it stems from a lack of trust maybe...not really sure, but I'm much more comfortable working with things I've built from the ground up. Hell, I'd rewrite PHP if I knew C.

Posted: Tue May 16, 2006 4:10 pm
by Nathaniel
Burrito wrote:I'd rewrite PHP if I knew C.
I love it.

I'm with Burrito, almost all of my stuff is homegrown. In fact, the only non-homegrown thing I can think of off-hand is McGruff's MAC class. Well done piece of work that was. Easy to use too.

Posted: Tue May 16, 2006 4:46 pm
by Ambush Commander
Hmm... looks like I should try to understand this authentication problem a little bit better then.

Posted: Tue May 16, 2006 5:22 pm
by Christopher
Ambush Commander wrote:Hmm... looks like I should try to understand this authentication problem a little bit better then.
Or ... start a thread and we can code the basics of it right here. I find it really helpful to work through a common problem as a group. Even if I don't end up using that code -- it always influences my own code.

I have tried to push code-in-forum sessions before, but the usual backlash against it is the fairly valid groaning about what a bad an idea "code by committee" is. But if we had some rules it might work. Say that you "owned" the code and managed the project. And perhaps there were 2-4 others who had voting rights on decisions about the project. Everyone else could give comments whenever they wanted. The voting group agrees on the steps and work their way through them: requirements, use cases, design, unit tests, code, etc.

Posted: Tue May 16, 2006 5:40 pm
by Ambush Commander
I'd be all for it. :)

Posted: Tue May 16, 2006 5:46 pm
by Christopher
We just need a couple of voter/contributors to give constructive input and play Devil's Advocate. I'll volunteer. Burrito or Nathaniel? Any interest in playing along? What should the (fairly loose) rules be?

Posted: Tue May 16, 2006 9:22 pm
by Nathaniel
I don't call myself an expert on authentication by any means, but I'd like to throw in a couple pennies and learn some things.

Re: Authentication Poll

Posted: Tue May 16, 2006 9:43 pm
by alex.barylski
Ambush Commander wrote:Short and quick. Maybe some reasons why things have ended up this way are nice. (yes, it's that time of the year again. The first two times I built an authentication system, things were painful, and I'm not so keen on repeating the experience, but from what I see, most prewritten classes are dreadfully deficient or clunky).

Other topics (a bit recent too, but I didn't feel like reviving dead threads):
* viewtopic.php?t=47735
* viewtopic.php?t=47407
I'm currently working on a security library...

I'm curious what you mean by:
The first two times I built an authentication system, things were painful, and I'm not so keen on repeating the experience, but from what I see, most prewritten classes are dreadfully deficient or clunky
What exactly did you mean by this? Currently as it stands...mine is pretty flexible and to the point...I'll be honest I have little experience with any third party software, except to look at it and steal ideas...thats it...

What features would you like to see in an authentication library?

Cheers :)

Posted: Tue May 16, 2006 9:55 pm
by alex.barylski
arborint wrote:We just need a couple of voter/contributors to give constructive input and play Devil's Advocate. I'll volunteer. Burrito or Nathaniel? Any interest in playing along? What should the (fairly loose) rules be?
I hate arguing but will do so to prove my point - as many of may already know...

I guess that makes me a devils advocate...post some code people :P

Cheers :)

Posted: Tue May 16, 2006 9:56 pm
by alex.barylski
I think people should seriously explain why they wrote a homegrown solution as opposed to using PEAR, etc...

I'm really curious to hear reasons, outside of...just cause...

Cheers :)

Posted: Tue May 16, 2006 10:01 pm
by Nathaniel
I find that my homegrown solutions are simpler because they only have the features I actually need for a project. They're also easier to add features into because I know them like the back of my hand. And they really don't take all that long if you understand the ins and outs of the problem - that is, once you've solved a problem once you can solve it again from scratch in minutes.

Posted: Tue May 16, 2006 10:07 pm
by Ambush Commander
PEAR::Auth - When I was a young grasshopper, I attempted to use Pear::Auth. The login callback function didn't make much sense to me. Furthermore, the class attempts to both authenticate and authorize, and fails miserably on the latter. General consensus out there seems to be don't use it.

PEAR::LiveUser - Supposedly it's a bit better, but it's got far too many dependencies. Without access to a PEAR installer (if there's one thing about PEAR I love, it's the installer) on the webhost this authentication system will be installed upon, it's a pain to maintain PEAR libraries (yes, I know they're optional, but don't tell me you're not going to have it interface with the database). This applies in general to most PEAR libraries. Plus is Beta, which is another strike against it.

PHPGACL - An interesting permissions system, but nothing too amazing. It requires a few other weighty third-party packages, and uses quite obscure terminology (if I was a non-tech savvy admin, I'd be lost in the jargon). And it's a bit overkill for what I have in mind.

I agree with Nathaniel: if you understand the problem, a homegrown solution will be simple and efficient, and perfectly suited to the task at hand. Furthermore, for one-man developing teams, it's beneficial that the developer knows about the component intimately, rather than having to learn a third-party system.

If I was looking for an authentication library, I would not be looking for so mcuh a library that let's me go $a->isUserAuthorized() but rather a toolkit with simple "components" that every authentication system has, and put them into a greater interface for the particular application being designed.

Posted: Tue May 16, 2006 10:14 pm
by alex.barylski
Nathaniel wrote:I find that my homegrown solutions are simpler because they only have the features I actually need for a project. They're also easier to add features into because I know them like the back of my hand. And they really don't take all that long if you understand the ins and outs of the problem - that is, once you've solved a problem once you can solve it again from scratch in minutes.
Can you give examples of what you mean?

I assume that eveyones requirements are different...like some may choose user/email/pass and others may just use some random promo code, etc...

perhaps one might include some sort of account lock if a user hasn't auth'ed in say more than 30 days...

What examples can you think of???

Honestly...every login I've ever done has been user/pass...email/pass...and that was it...so i'm trying to think of others scenarios...to see if my login code will work in any situation...

Cheers :)

Posted: Tue May 16, 2006 10:23 pm
by RobertGonzalez
OK, I had to get in on this thread...

I have never used a PEAR library. I toyed, once, with phplib (templates), but ditched the idea about five seconds after I looked over the code.

I have reused snippets of code from other open source/free-ware apps at various times, but for the most part I code my own app components. I like having the control to make my components do what is necessary, and only what is necessary, for the app. I also like making my code very modular, something that all developers do not always attempt to do. But that is just me.

I kinda like the idea of a code-by-group thing. I might want to get in on something like that if it ever materializes.