Re: [Phplib-users] New phpauth code

[Michael C. <mdc...@mi...>]

On Mon, May 06, 2002 at 05:38:40PM -0500, Layne Weathers wrote:
> > I've been promising this for a year, but it's undergone plenty of
> > refinement to make it worthwhile.
> >
> > You can download my new phpauth code at:
> > http://www.phpauth.com/
> >
> > This is a replacement for the authentication functionality of phplib.
> > It only works with php4, and relies on php4's sessioning.  It
> > works with
> > register_globals turned off, and requires that magic_quotes also be
> > turned off.  It's nearly a drop-in replacement for phplib.
> 
> 
> Really?
>  - You use a copy of PHPLib's db_mysql.inc from 1999 - what else is out of
> date?

Nothing major has changed that I know of in the db class.  It works
fine.

>  - You want me to use inline PHP and HTML. Why would I revert to ineligantly
> located, hard-to-update markup when I have discovered the one true religion
> of templates?

I don't want you to do anything.  I don't care what you do.  As for me,
I use standard HTML 4, with stylesheets, which works great for what I
do.  If it doesn't work for you, I don't care.

>  - You ask me to learn a new API and change my handling of auth, perms and
> cart.

I don't ask you to learn anything.  I present a piece of code that you might
find useful.  If you don't, then move on.

> 
> > I am using this code on 5 production sites currently, so it
> > should work
> > fine.
> 
> 
> I use PHPLib on dozens of sites across half a dozen production servers;
> thousands of other sites use PHPLib as well. There is a difference between
> code that works and a library that can be used by thousands of developers to
> fit their distinct needs. I do not think that PHPLib is perfect, but it has
> fit the needs of many developers.

phplib started somewhere, certainly not on thousands of sites.  The
phpauth code is far more flexible than phplib's equivalent pieces in
many ways, and will easily fit the needs of any php developer who
doesn't use templates.  The template code would probably work with
little or no effort, anyway.

> > If you're looking at an easy upgrade path from phplib for
> > php4, this is
> > it.
> >
> > A few of the features that separate it from phplib:
> >
> > 1. uses php4 sessioning
> 
> This appeared in PHPLib's development branch in 2000 and was moved into the
> production branch a few months ago.
> 
> > 2. register_globals off (more secure)
> 
> This has been fixed in PHPLib.
> 
> > 3. form variables are passed through login/registration forms
> 
> This is an easy modification and has been described on the PHPLib list a few
> times.

Due to the fact that form variables aren't well named in phplib, some
changes are necessary to make it work globally.

> > 4. auth class doesn't exist unless they are authenticated
> 
> I'm not sure that I understand this. If the code to authenticate a user
> doesn't exist, how can they be authenticated? Do you mean instead that there
> is no auth object in memory?

That's a screwup on my part.  Should read "auth object doesn't
exist...."

> I have not thoroughly inspected your code, but what I have seen indicates
> that you have dismissed many of the design decisions followed in the PHPLib
> classes. Why?

I've dismissed very little.  The biggest problem that I had with
phplib's auth class was that the existence of an auth object didn't mean
the user was authenticated.  Indeed, even the "is_authenticated"
function didn't work properly, as it would return "form" if the user was
in the process of logging in.  Checking for authentication meant going
through the convoluted steps of checking for an auth object, seeing if
is_authenticated returned anything, and if so making sure it wasn't
"form".  Now, it's a simple check for the existence of an auth object in
the $_SESSION global.

Additionally, the separate perm object didn't make sense to me.  Nor did
the inclusion of various files (headers, etc.) which sometimes resulted
in confusion of scope (header might be included in global scope, or from
within the auth object if logging in or registering).

And I made this have the functionality to place a permanent cookie for
authentication.

The original reason that I wrote this new code was simply because I
needed to authenticate using a flat file of usernames and passwords.
That and the fact that I was using php4 and needed new sessioning.

> Over the past few years, I have found the experience of the
> PHPLib community to be quite valuable. I continue to discover flexibility in
> PHPLib that I did not expect and find new ways to use the codebase.
> 
> It seems that your biggest problem with PHPLib is that the development of
> new features has not met your expectations. It hasn't met mine either (as a
> developer, that means that I haven't met my own expectations). However, by
> working on and with PHPLib, I am able to leverage countless hours of quality
> programming to shorten my production time and improve my bottom line.
> 
> There are many factors that affect our decisions to work on any given
> project. If you are sure that working on the phpauth code is where your
> priorities are, then I wish you luck with it. If not, please consider
> contributing to PHPLib.

The fact that I bought phpauth.com should be your first clue that this
is where my priorities are.  If you read my docs, you'll see that I was
and remain quite impressed with phplib.  There are a few fundamental
problems that I have with it, and I have attempted to solve them with my
new code.  These problems involve the fundamental architecture of the
auth class that they present, working on it doesn't make sense.

If you don't like it, that's fine with me.  As for the rest of us, I
hope that others find it useful.  If not, no biggy as I will continue to
use it for my stuff (with at least one other person that I know of using
it, too).

Michael
-- 
Michael Darrin Chaney
mdc...@mi...
http://www.michaelchaney.com/