phplib-users

RE: [Phplib-users] New phpauth code

[Layne W. <la...@if...>]

> > I try to register in your site, but get response that my
> email is invalid.
> > Althought my email is valid for years (not this but other).
>
> The email address is checked against a simple regular expression.
> preg_match('/^([a-z0-9\-_\.\&]+)@([a-z0-9\-]+\.)+[a-z]+$/',$email);
> I assume you're mixing case (email addresses and domain names are case
> insensitive).

If email addresses are case insensitive, why do you force your (lower) case
preference? Using uppercase letters is quite valid and often makes email
addresses more human-readable.

In addition to checking email addresses against a simple format, I check
against all known TLDs. I also find it useful to warn users if I cannot find
an MX record for their domain. This prevents numerous "us...@ho..."
attempts.

Layne Weathers
Ifworld Inc.

RE: [Phplib-users] New phpauth code

[Layne W. <la...@if...>]

> 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?
 - 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?
 - You ask me to learn a new API and change my handling of auth, perms and
cart.


> 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.


> 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.

> 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?


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? 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.


Layne Weathers
Ifworld Inc.

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/

Re: [Phplib-users] New phpauth code

[Richard A. <rh...@ju...>]

At 6:13 PM -0500 6/5/02, Michael Chaney wrote:

>If it doesn't work for you, I don't care.

Nice attitude.

 ...R.

Re: [Phplib-users] New phpauth code

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

On Tue, May 07, 2002 at 09:25:56AM +1000, Richard Archer wrote:
> At 6:13 PM -0500 6/5/02, Michael Chaney wrote:
> 
> >If it doesn't work for you, I don't care.
> 
> Nice attitude.

It is, actually.  I put my code up, and get a long reply where he tells
me that it doesn't work for his particular situation.

I can name 100 pieces of software that don't work for my situation.  I
don't use Windows XP, Adobe Photoshop, Macromedia Flash, MS-DOS, Novell
Netware, the list goes on and on and on.

But I don't bother alerting these companies to the fact that I don't use
their software.  They don't care.

It is my hope that my software is useful to others.  If it isn't, too
bad.  It's useful to me, and it is useful to some other people who are
already using it.

If it doesn't fit somebody's needs in particular, well, hopefully they
can get those needs met elsewhere.  But it's not my problem.

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

Re: [Phplib-users] New phpauth code

[Giancarlo P. <gia...@na...>]

> 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.

An he wsn't 'nobody'!

> 
> 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).
> 
......
> new code.  These problems involve the fundamental architecture of the
> auth class that they present, working on it doesn't make sense.


I came to this same conclusion about the intrinsic obsolescence of
auth and perm. I was also trying to incorporate them with 'user', and
have a single object, and keep them clean from the phisical way of
interaction with the client. So have the 'form' state eventually
handled outside this that I called the BigUser object, by the page
funcions.

I have no time now to check phpauth, I'll see it as soon as I am back
to php for any project. 
But am courious about what users think of

Giancarlo

RE: [Phplib-users] New phpauth code

[Layne W. <la...@if...>]

> I generally force the username to lowercase before doing the
> check, and
> this code should do that (it's not rocket science to implement it).
> I'll probably make that change.
>
> I won't allow case-sensitive matching.  I've done it before, and
> inevitably someone ends up typing in a couple of caps in their email
> address, then they can't understand why it won't work next time when
> they don't.  Same with passwords, sad to say.


Whoa! People use mixed case passwords for added security. You're lowering
the security of your users' data by forcing lowercase passwords? For email
addresses, MySQL searches case-insensitively, so why should we care how they
enter it?


> > In addition to checking email addresses against a simple
> format, I check
> > against all known TLDs. I also find it useful to warn users
> if I cannot find
> > an MX record for their domain. This prevents numerous
> "us...@ho..."
> > attempts.
>
> That's not a bad idea.  Have any code which you'd like to share?


I started with Validator 1.2 from thewebmasters.net and changed is_email()
to use this new function:

function has_mx($host) {
	exec("nslookup -type=mx $host", $return);
	if(is_array($return)) $return = join("\n", $return);
	if(is_integer(strpos($return, "mail exchanger"))) return true;
	return false;
}


Layne Weathers
Ifworld Inc.

[Phplib-users] where is New phpauth code

[John L. <jo...@li...>]

hello,

Im wondering where I can get the new phpauth code.

I think I deleted the email with that info previously.

John

RE: [Phplib-users] New phpauth code

[Brian P. <bp...@ct...>]

Relax people. This thread reminds me one of those nature-channel
documentaries where the two dominant males are killing each other in order
to impress a nearby female. In case you didn't know, there are no females
here! And, if there are females here, they could care less which auth class
is better. :)

If phpauth is better, time will tell.

Incidentally, the template class doesn't appear to be logically linked to
phplib in any way. You could, hypothetically, include 'template.inc' and
nothing else.

-bpopp

-----Original Message-----
From: Michael Chaney [mailto:mdc...@mi...]
Sent: Tuesday, May 07, 2002 9:39 AM
To: Tarique Sani <ta...@sa...>
Cc: 'phplib-users'
Subject: Re: [Phplib-users] New phpauth code


On Tue, May 07, 2002 at 10:23:12AM +0530, Tarique Sani
<ta...@sa...> wrote:
> On Mon, 6 May 2002, Michael Chaney wrote:
> 
> > I've been promising this for a year, but it's undergone plenty of
> > refinement to make it worthwhile.
> 
> Great!!
>  
> I presume you are not asking it to be integrated with PHPlib 
> 
> Are you?

Indeed, your presumption is right.  For those not using the templating
system in phplib, I believe that I have a better alternative.  Again,
this isn't a slam on phplib, I have a lot more flexibility since I don't
need to be backward compatible.

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

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: ban...@so...
_______________________________________________
Phplib-users mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phplib-users

Re: [Phplib-users] New phpauth code

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

On Mon, May 06, 2002 at 04:08:38PM -0500, Layne Weathers wrote:
> > > I try to register in your site, but get response that my
> > email is invalid.
> > > Althought my email is valid for years (not this but other).
> >
> > The email address is checked against a simple regular expression.
> > preg_match('/^([a-z0-9\-_\.\&]+)@([a-z0-9\-]+\.)+[a-z]+$/',$email);
> > I assume you're mixing case (email addresses and domain names are case
> > insensitive).
> 
> If email addresses are case insensitive, why do you force your (lower) case
> preference? Using uppercase letters is quite valid and often makes email
> addresses more human-readable.

I generally force the username to lowercase before doing the check, and
this code should do that (it's not rocket science to implement it).
I'll probably make that change.

I won't allow case-sensitive matching.  I've done it before, and
inevitably someone ends up typing in a couple of caps in their email
address, then they can't understand why it won't work next time when
they don't.  Same with passwords, sad to say.

> In addition to checking email addresses against a simple format, I check
> against all known TLDs. I also find it useful to warn users if I cannot find
> an MX record for their domain. This prevents numerous "us...@ho..."
> attempts.

That's not a bad idea.  Have any code which you'd like to share?

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