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

giancarlo pinerolo wrote:
>
> Ben Curtis wrote:
>
> > 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...
> >

Sorry. I supposed here, by 'pre-existing app's user list', you meant the
array struct, the user persistent slice of data.

>
> Here the ideas come to a bitter end... but here is less important,
> because we are talking about per_user data, not per_site authentication.
> What can I say... if you put it all under an array in user, naming the
> array an the class something uniquely findable by a mass search &
> replace, th eadmin can have an easier life.

If, with 'pre-existing app's user list', you intended the list of users
in the site's phplib 'auth_user' table, once your app respects the 3 or
4 fields definitions necessary to phplib auth, user_id, username,
password etc, (you can add extra table fields though), it uses that same
table. Or vv. the admin uses phpbt auth_user table to add his future
users, if he's new to phplib. Of course this all presumes that one wants
to merge all his users, and differencing them by other means (eg the
existance of a user's persistant phpbt array). I wouldn't like to have
as many users tables as applications. But I don't know all the cases..

G 

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