Core Auth Library

[eluser]jedd[/eluser]
[quote author="thody" date="1250314779"]
With all due respect, I'd love to hear of the last web-based application you signed up for that didn't require you to enter an email address. Practically speaking, it is requirement for 99% of modern web systems. [/quote]

I wrote one, actually, a few years ago. Before my CI days, but coincidentally, had I been a CI user at the time, it would have been a system that a very basic and generic auth system like this would have been perfect for. In any case, the client wanted something for the parents of kids at a particular school to be able to use, a very simple trading-post style system for equipment, books, uniforms etc. Email was specifically avoided as a prereq.

My point is, was, and will remain - a generic system should aim for coverage of 100%. It should allow for being plugged into extant auth systems (think ldap, radius, etc) where you might be caching credentials from elsewhere (and where you want to duplicate, or at least shadow, the bare minimum of fields - just enough to uniquely identify a user). I'm not suggesting that this library provide code for caching and updating credential changes to such systems (I've done some work with Novell's IDM and know that getting different auth systems to talk to each other is a huge and messy quagmire).

While 99% of modern systems doubtless do track a user's email address, I'd suggest that 99% of modern systems track a bunch of other stuff - flags for locked and/or banned, last IP address, last login time, first name, surname, appellation, creation date, and so on.

Presumably, in the predicted usage pattern for an abstracted auth library, that information is kept elsewhere.

I'm suggesting email address be kept in the same category, and/or not be assumed to exist, and/or not have any special functions created for it (as I think your current HEAD is already heading towards, or has achieved, in any case). (Digression: from a practical POV, I'd also suggest that assuming email addresses are UNIQUE within the table is a mistake - the only absolutely-must-be-unique-fields are user.id and user.handle (IMO).)

Now .. I think that this highlights a design problem we should address - how do we handle user details - do we ack they exist and provide a generic (but probably useless) interface for eg. get user_details ($field_name) and leave it to the programmer to track the fields forever using generic methods - do we assume that there'll be a user table, as per the current schema, that contains nothing but user and pass and ID (I think this is a bad assumption) - do we provide that as a base and tell the library user that they can alter it to their heart's content - do we look at using a VIEW that maps our pseudo-user table over whatever current user table(s) the system has, such that our VIEW matches our expectations, whilst not getting in the way of any pre-existing components or forcing any unwanted design decisions on the library user?

I have no experience with using VIEWs, but I gather this is an ideal use case for them - as I don't imagine anyone would want a table that contains just id/handle/password-hash, as it'd be a duplication, in part, of whatever other tables they're using to track user data. I think, but happily defer to anyone with a clue about views, that it would provide for a simpler installation & configuration process - 'here's a view statement, modify this bit here and that bit there with whatever column in whatever table refers to your user ID and handle, and then run it'.