I’m an admin. Most of what I do with PHP and MySQL is maintain. [On rare, rare occasions, I work on code. Now that I'm back in graduate school, rare is also defined as "never".] One problem that I see that desperately needs solving: a common user database that has great, simple API hooks.
What’s the point?
If you have more than one package that uses PHP to manipulate and represent MySQL data, you’ve undoubtedly wished for commonality in your user databases. If you run a Weblog-as-CMS and a forum, you’re probably wishing, “Man, why can’t WordPress and phpBB talk to each other?” [I mention those two only because they're the most popular such choices; I've largely moved from phpBB to SMF, and I'm also experimenting with TextPattern as a WordPress replacement in situations where it might be more attuned to my needs.] I think they should.
What are the parameters you’d need?
This database needs to be dead simple, because having data in a separate table [or database] just adds complexity to the query, and this complexity will add overhead. So, with a minimalist ethos being the wind beneath our wings, let’s take off:
User_id: A simple incrementing counter. Because this is stored as an integer, it’ll be useful to have for your API hooks, because you’re passing smaller and more digestible data than the username [see below].
Username: User’s email address. Having a separate username and email makes no sense to me—and because people do change their email addresses and often forget who all has the old one, having the username as the user-email solves all sorts of issues. Not only is this good for the user, but it’s also good for the administrator—no more table lookups to find the username of someone who emails you with a lost account request!
Password: Stored as an MD5 hash of the user input. This is industry standard.
Date created: Automagically generated.
Date modified: Automagically generated. This is important because it’s good to have a record of when stuff is changed for security purposes.
User handle / display name: It’s important to have this in the system, because a good package like this should never display the user’s email address to all the screen-scraping spammers of the world. Also, we don’t want confusion when people change their email addresses.
And that’s really it. Authentication should be handled with cookies, and API hooks should support sessions.
This would be a hugely beneficial open-source project, and should be licensed liberally rather than with the GPL, because I don’t want to see commercial products locked out of this. Commonality is an important thing.
[And yes, some will argue that this is very close to LDAP, or that you should make it Kerberos-like. Knock yourselves out---I haven't seen a good implementation of either in the Web-based scripting environment of the day.]
Hmm, sounds great! You have no idea how many times I’ve wanted this!
As for building the APIs, I really wouldn’t know where to begin, but writing the code to handle the unified database would be simple.
Now, in your vision is this a downloadable package that lets a single administrator setup one global user database for all their sites, or is it a totally public user database for all to hit and allow a user a one global internet identity?
A global identity service sounds the most useful (to me personally), and a lot like Microsoft Passport (now defunct?) or the AOL Screenname service, just free and non-corporate and not privacy-concern riddled…
Now the one thing I’ve always wondered about these services… If I join and get access to the global database to authenticate my users, what’s to stop me from mining data out of the global database and stealing the identities of users, since they’ve got essentially the same password… everywhere?
I’m thinking the former. The latter would have utility, but centralization of such resources seems unlikely to scale. I’m just looking for a way to have a unified login for packages like WordPress, phpBB/SMF, something like MediaWiki, and whatever custom applications I build on my own to manage data. I think building these applications gets simpler at some level if there’s a common user-authentication schema out there for developers to use—you worry less about identity and more about user capability.
Your conscience. That’s why I don’t think that these services should be wholly centralized. I think we’re just looking for community support. To go much larger just makes it a far more inviting target for crackers.
Well now this one is somewhat easy to do… One simple class. I’ll think on it and throw together some specs as I do and see if I can come up with something after exams are over (last is Saturday). If you’ve got any particular “I want x to return data like this” cases or “ohh, it’d be nice if it’d do that” scenarios, let me know.
The tough part is going to be database interaction. Personally, I’m strictly a MySQL guy, but I’d like to be as open with the possibilities as possible. Bah, one step at a time…
I recommend adding a date_created field into this table, so it is known when the user joined.
And if you’re using a double-opt-in system, I recommend adding a user_act_key field (or putting this into a separate table associated by user_id since it will be null once the user has verified their email address).
That way whenever the user changes their email address, your system will know to verify it first, and if the account expires, you can pull the record (saving space).
How about Deadlock?
Deadlock is an open source user authentication/password protection system written in PHP/MySQL and licensed under the GNU GPL. It uses .htpasswd and .htaccess files to protect any web directory. Installation is as easy as running a setup script.
http://www.phpdeadlock.org/
If you don’t need anything so comprehensive, there’s a PHP admin system with login features at:
http://evolt.org/PHP-Login-System-with-Admin-Features
William: Deadlock looks ill-suited to what I’m using, but the evolt system does look better. Thanks for the tip.