[phplib] Expanding auth_user From: Brian Popp (bpopp <email protected>)
Date: 08/22/01

Somewhat related to the 'current users' thread, I'm curious whether most
people are expanding on the auth_user table (adding first name, last name,
phone #, etc), or whether they create their own User table and relate it to
the auth_user table on user_id.

I've tried it both ways and haven't decided which I like better. Adding
fields to auth_user is much easier, but something about it bothers me. I
haven't figured out exactly what?

I guess one advantage to splitting contact information out into another
table (or tables) could be that you could have multiple types of users, each
that needs to have different information collected in a separate table. For
example, a book publishing company might have Authors, Editors, Employees,
etc. With authors you might want to collect different types of contact
information than with editors and employees. You could make your auth_user
table one enormous table that encompasses all user types, but I think it's
probably cleaner to split them out and make the tables as specific as
possible.

Yay? Nay? Who cares? :)

bpopp - bpopp.net

-----Original Message-----
From: giancarlo pinerolo [mailto:giancarlo <email protected>]
Sent: Wednesday, August 22, 2001 11:26 AM
To: Ben Curtis
Cc: phplib-users; phplib <email protected>
Subject: [phplib] Re: [Phplib-users] Re: [phplib] current users?

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.

I mean, this is the idea. Would this make any sense with the way your
package works?

Giancarlo

>
> On Wed, Aug 22, 2001 at 09:00:07AM -0400, Stephen Woodbridge wrote:
> > giancarlo pinerolo wrote:
> > >
> > > What I propose is to make Auth a very aseptic class. Kind of
> > > client-server. Loosely coulpled. No html ouptut, no form handling.
That
> > > stuff should be handled, eventually, by the application, maybe in
> >
> > [snip large and useful post]
> >
> > I am sorry, I did not comment earlier, but I thought you were right on
> > track with your ideas and suggestions.
> >
> > I have wanted to create a login capability similar to PHP-Nuke (ie:
> > login form on the pages rather than a separate page) for my phplib
> > applications. I will try to use your ideas and the code you supplied on
> > your post here.
> >
> > Thank you for your efforts and contibutions to the list.
> >
> > -Steve
> >
> > _______________________________________________
> > Phplib-users mailing list
> > Phplib-users <email protected>
> > http://lists.sourceforge.net/lists/listinfo/phplib-users
>
> _______________________________________________
> Phplib-users mailing list
> Phplib-users <email protected>
> http://lists.sourceforge.net/lists/listinfo/phplib-users 

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

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