[Phplib-users] Re: preexisting auth integration

[Ben C. <php...@be...>]

On Thu, Aug 23, 2001 at 11:38:00AM +0200, giancarlo pinerolo wrote:
> 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...

Well, we all tend to have our perception colored by our experience and frame of reference, right?  :)

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

Thanks for taking a look at it, and thanks for the compliment.  Also, thanks for the nice analysis and suggestions below...

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

Right, I saved that thread so I when I get a few spare minutes I can implement those ideas into my schema.  It is definitely a flexible and valuable way to manage users.

> 
> 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())

Yeah, I really geared this towards an internal testing/dev team, so stuffing the user table with bad email addresses and kicking out lots of emails wouldn't be an issue.  

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

Like the posts in response to this on the other list, if I were to do a two-phase sign-up, I would insert the record as an inactive user, and then bump that up to regular user upon first login.  I also liked the idea of forcing a password change at that point.

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

You raise some valid points, which I have been thinking about as one of the users of my package wants to separate the login username from the email address.  I have a little experience in integrating the auths from two phplib-based packages (trying to get phpBB v2 working with a pre-existing site).  Now, in this case, the phpBB guys saw fit to eviscerate phplib and re-invent the wheel.  Regardless of how relevant that may be to this conversation, the point is I had to gut their stuff to check against our login/auth while putting enough data in their tables to get phpBB to work.  In the end that meant all the user interactions in the pre-exising app (login, logout, user info modification) had to be copied over to the relevant places in their tables.

So, that was a tangent, and certainly work in easing integration b/w phplib-based apps is needed... but back to phpbugtracker. :)  I probably should break out the username/login and email address into separate fields, giving the admin flexibility to choose whether or not to use the email address as the login.  I think the changes will appear sometime in the next few weeks, so maybe I'll report back and have you critique it again. :)  Of course, that still leaves the question of how to nicely get a pre-existing app's user list into phpbt and vice-versa...

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