+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived General Discussion (https://forum.codeigniter.com/forumdisplay.php?fid=21)
+--- Thread: Core Auth Library (/showthread.php?tid=21526)
Core Auth Library - El Forum - 08-14-2009
[eluser]Circuitbomb[/eluser]
[quote author="Rick Jolly" date="1250290144"]A core auth library must be totally generic, making no assumptions. A few lines of code, and something every developer can do in a couple minutes. That's why there isn't auth in the core. ACL is a different story.
thody, your attempt is already too specific. Username, id, and email could all be the same thing. Don't store a user in the session, just their id. Reason being, if an admin changes any user credentials, they won't update for a logged-in user until their session expires. Don't use a get_attr() method when php magic methods will accomplish the same thing. Also, don't dismiss the dozens of existing auth libraries. At the very least, you could learn something from them.[/quote]
I would think that the point of id/username/email combinations would be that they are different, but unique to only the individual member. Of course one of any of those variables could be used to identify a member, but why use one, when one of the other two may have a specific usefulness in any multi-user system.
I think that in any user system those three forms need to be present, and are the generic values that need met at the least. How does storing the id update changes for a logged in user while the session is still alive compared to if you used the username? I would think that the session would still need to die or be regenerated in order to see the changes regardless of which one you used.
The only difference I see would be the number of characters used.
Core Auth Library - El Forum - 08-14-2009
[eluser]Rick Jolly[/eluser]
[quote author="Circuitbomb" date="1250294183"]
I would think that the point of id/username/email combinations would be that they are different, but unique to only the individual member. Of course one of any of those variables could be used to identify a member, but why use one, when one of the other two may have a specific usefulness in any system.
I think that in any user system those three forms need to be present, and are the generic values that need met at the least. How does storing the id update changes for a logged in user while the session is still alive compared to if you used the username? I would think that the session would still need to die or be regenerated in order to see the changes regardless of which one you used.
The only difference I see would be the number of characters used.[/quote]
Maybe I wasn't clear. An auth library can only assume id and password. That id could either be a number, an email address, or a username. The library couldn't assume which one to use, and definitely couldn't assume all three.
Core Auth Library - El Forum - 08-14-2009
[eluser]Rick Jolly[/eluser]
[quote author="Circuitbomb" date="1250294183"]I would think that the session would still need to die or be regenerated in order to see the changes regardless of which one you used.
[/quote]
My point is that the session should only store one unchanging id, not the entire set of user data. The id will never change, but the data may. So the session wouldn't have to expire/genererate to show updated user data.
Core Auth Library - El Forum - 08-14-2009
[eluser]jedd[/eluser]
[quote author="Circuitbomb" date="1250293136"]
Storing an email session side could limit the amount of calls to a database if the system has a heavy amount of traffic. Grabbing a session var would be faster than calling the database in most cases, and likely done with less code since to set the var in the first place would only really require one call with each session creation.
[/quote]
Sure, but this is the eternal trade-off - at one end you have the philosophy of dumping the entire database into an array.
My point was that the owner's email address is rarely used - at least in my experience. ID and login-name (or handle) are used in pretty much every view - again, in my experience.
And then there's this ...
Quote:As with what thody stated, I couldn't imagine a member system which did not require an email address.
If you can not imagine a system that allows for users without email addresses, then you should not be involved in the design of an abstracted authentication system.
Quote:Performance issues can always be tweaked in php.ini settings as well, if the developer has access to those configurations, and in some cases if they do not, within .htaccess.
I think this is an inconsiderate approach - putting performance considerations over to later-day operations staff, rather than sufficiently contemplating them during the design phase.
Core Auth Library - El Forum - 08-14-2009
[eluser]thody[/eluser]
[quote author="jedd" date="1250299266"]If you can not imagine a system that allows for users without email addresses, then you should not be involved in the design of an abstracted authentication system.[/quote]
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.
Regardless, we're looking at a library that has existed for 48 hours, if the option to exclude email address is deemed necessary, we can easily account for that. Open source should be a conversation, not a proclamation. No need to get one's shorts in a knot, just make your case and it will be heard.
Regarding id vs. username vs. email: it's clear that there should be a singular unique key, but it's dually noted that no particular key will prevail as the crowd favourite. The only remaining option is to enable the flexibility for the developer to select the unique key of their choosing. This can easily be done with a few lines of code and presents a minor obstacle.
The underlying point of this post is that very few decisions have been made at this point. If you feel strongly about a certain point, please voice your concern, and we'll all benefit by generating a stronger auth library as a result.
Core Auth Library - El Forum - 08-16-2009
[eluser]skunkbad[/eluser]
I'm going to release my auth system soon. Very soon. I just sent it to Cb for testing, because I want to have somebody elses eyes look it over before releasing it. Maybe it will meet your needs?
I had said that I thought this might not be in my best interest, but I was set straight. The community can only make it stronger. If you're a php guru, and want to look it over for any bugs or security concerns, send me a message.
Core Auth Library - El Forum - 08-16-2009
[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'.
Core Auth Library - El Forum - 08-16-2009
[eluser]jpi[/eluser]
In my opinion, the best solution would be to just copy ZF Auth classes. Its mechanisms are really powerful. I feel it gives developper a lot of flexibility. But it must be rewritten in CI because Zend_auth use Zend_DB for its database adapter.
Core Auth Library - El Forum - 08-16-2009
[eluser]skunkbad[/eluser]
[quote author="jedd" date="1250442144"]...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?...[/quote]
I think all user account data goes in one table, and so yes nearly every project where auth is integrated will require changing the user table. You can and should limit field access by query, and CI does this nicely with $this->db->select()
Core Auth Library - El Forum - 08-16-2009
[eluser]thody[/eluser]
[quote author="jpi" date="1250452957"]In my opinion, the best solution would be to just copy ZF Auth classes. Its mechanisms are really powerful. I feel it gives developper a lot of flexibility. But it must be rewritten in CI because Zend_auth use Zend_DB for its database adapter.[/quote]
I think there's definitely lots to learn from the Zend_auth approach. I'm particularly fond of extracting the specifics out to separate adapters, especially given that many sites offer multiple forms of authentication now (db, Facebook Connect, oAuth, etc).