[phplib] preexisting auth integration From: giancarlo pinerolo (giancarlo <email protected>)
Date: 08/23/01

Yep.
You must pardon me. I know I have the defect that when I start hammering
everyone with some of my ideas, I become less perceptive on other
people's ideas. I should listen more and give more value at others
then...

I downloaded the latest cvs of phpbugtraq and it is a very nice
application.

And I'd be glad to try to apply to it those kinda 'guidelines for
respecting preexisting auth' that I am trying to endorse/enforce.

So I took a look at the phpbt auth stuff.

PHPlib's auth_user table comes with a predefined set of fields:

user_id
username
password
perms

As kk wrote in a recent message, you could freely add more fields to
that table if you need, as long as you keep these, without compromising
the way phplib auth works.

I understand that a bug traquing applicaton needs users' email. And a
valid one too. So phpbt checks that by sending an email with a random
chosen password to the address entered.
This as I see is not a two-step confirmation. No reply is expected from
the user receiving the email with the passwd upon registering.
In fact I see that you are writing the user record with the random
assigned password and send it by email, in one single go, in the
registering action (newaccount.php -> do_form())

This is interesting because it poses another side question: what should
be if it was a two-phase action? I mean, if the email pretended to
receive a confirmation? What would be the state of that user in the
meanwhile? registered? pending (something similar to the actual
$auth[uid]='form' state)?
These are all ideas and problems that come out when somebody (me) starts
to apply a theary to some practical case. I see that most applications
that require an email confirmation for a registration, tend to keep a
separate file/table for pending_subs, and only after clearing that, the
actual registration takes place. To dig...

Anyway, back to phpbt, as it is a one-phase registration, the problem
doesn't apply here.

Now keep in mind that I am analyzing you app under *my* point of view,
basically because I am trying to see if/how it could conform to *my*
idea on 'guidelines for respecting preexisting auth'. I am not meaning
that you should have made the same thoughts, by no mean. You chose to do
it that way and it is perfectly sane. I just choose phpbt because you
are actually one of the first package developers that seems to show some
interest in this theory, and I see that phpbugtraq is one of the rare
phplib-based apps that do not come bundled with phplib, which is already
a great thing.

So you are needing the email here. The fact that you made the login-nick
be the emailaddr, is an optional choice. One could have already his
logins that are not the email addresses, or that are. That makes little
difference. What makes the difference is that you used a different table
definition. The field 'username' in phpbt user tables doesn't exist
anymore, it is called 'email' phpbt, proably for semplicity and
reminding admins that it contains in fact the email addr. A minor
reason, that (in *my* theory, remember), brings to a major unconsistency
and integration problems

So how to integrate this in a site that doesn't store emailaddr in the
'username' field? Simply add an extra 'email' field, and store it there.
In brief:

-if there is a preexisting auth and already uses the emailaddr as
login-nick, and it is stored in the 'username' field of the table,
he'd have to add and 'email' field anyway for your app to work. It
will not break anything on his site.

-if there is a preexisting auth that uses a user-chosen login nickname
(and stores it in the 'username' field), add an 'email' field to the
table and store it there. Again, it won't break anything.

-if there is no preexisting auth, but you want to let the admin install
more phplib-based packages afterwards without hassle, give him a choiche
while setting up phpbt and his site auth: he could set a nickname in
'username' and the emailaddr in a 'email' field if he wanted to have
nickname!=emailaddr, otherwise store the emailaddr in both the
'username' and in the extra 'email' fields. But keep the table field
named 'username' in any case.

And when phpbt makes its SELECT to validate, it always select the
username/password fields. and gets the email from the 'email' field. If
then the username also contains the email, you can't care less, it's the
admin choice.

Pls tell me if I am wrong.

Giancarlo

I myself wrote:

> But if I were to integrate that into my existing auth, I confess I'd get
> quite stuck. I don't use the email as login. And I see that you don't
> use the 'user' storage class. That could be a more suitable place to
> store things like 'bug_list_fields', first name, last name, etc.,
> instead of extending the sess[auth] array...
>
> The idea should be: extend what you want, but leave and use the (any)
> existing auth. Add users and grups to the auth tables if you need. Stuff
> like: lists of prerogatives, permission/permitted on objects, allowed
> paths or visitable documents, whatever, should stay in user.
>
> Apart from hat, I think you decided to provide your particular auth
> extension because of the way 'page' and 'forms' where displayed... which
> would confirm my opinion. The invasive handling of form interaction by
> auth, obliges a package writer to provide his own.
> Which is absurd.
>
> - Gian
>
> > As far as integration is concerned, since I extend the Auth class as per the phplib documentation, a user wanting to integrate my package with the rest of his code would just replace my auth_validatelogin(), either by editing or by changing the class extension. My installation instructions do tell the user to install phplib if not already installed, and that's all they have to do, since I extend the basic Auth class.
> >
> > Perhaps you should take a look at what I've done to see how I've done it.
> >
> > On Wed, Aug 22, 2001 at 06:26:20PM +0200, giancarlo pinerolo wrote:
> > > Ben Curtis wrote:
> > > >
> > > > For all the discussion about this type of functionality on this phplib list and the previous one, it's really not that difficult to implement. I have a login area on every page with my application, phpBugTracker (http://phpbt.sourceforge.net/). All you have to do is use the default auth and handle the login form yourself instead of relying on auth_loginform().
> > >
> > > I suppose you mean 'auth_preauth' instead of 'default auth'..
> > >
> > > That?'s Ok. but when someone installs your package on a site that
> > > already has phplib, but doesn't use preauth (or uses his devidsed form
> > > of),
> > > he's going to have big problems integratig the two, mostly if he,
> > > logically,
> > > wants to keep its base of current users (and groups in the near future)
> > >
> > > For me the very first, next logical thing to auth is keeping a log of
> > > logins/logouts. More than handling the form interaction, which is
> > > something that I'd throw out to the application side.
> > >
> > > Your application should tell the admin:
> > > if you don't hae already, pick-up and install phplib, with any auth you
> > > like (crc/no crc, log/reg, md5/no_md5. Do as you like).
> > > Then add new groups of users, ar extend the existing ones, to provide
> > > the desired permission to work with muy phpBugTraq app. Of course, do
> > > not use preauth. 

-- 
Abbestellen mit Mail an:   phplib-unsubscribe <email protected>
Kommandoliste mit Mail an: phplib-help <email protected>