Re: [phplib] Re: [Phplib-users] Re: preexisting auth integration
Brought to you by:
nhruby,
richardarcher
From: giancarlo p. <gia...@na...> - 2001-08-23 22:33:54
|
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 |