| Core Auth Library |
[eluser]jedd[/eluser]
And lo, we come full circle. I would be unlikely to use a library that assumed the user had an email address, let alone wasted session data space on it. I think the biggest problem that befell many of the other extant auth libraries is that they were coded, in some cases by very smart people, without checking what was required by the target audience. The second problem is that the target audience, if queried, would be unlikely to respond, and if they did, they'd be shown to disagree on pretty much everything.
[eluser]thody[/eluser]
@jayrulez: Good call. Especially important, since I'll be adding the ability to store additional meta data for users. One universal get_attr method would be nice.
[eluser]thody[/eluser]
[quote author="jedd" date="1250277538"]And lo, we come full circle. I would be unlikely to use a library that assumed the user had an email address, let alone wasted session data space on it. I think the biggest problem that befell many of the other extant auth libraries is that they were coded, in some cases by very smart people, without checking what was required by the target audience. The second problem is that the target audience, if queried, would be unlikely to respond, and if they did, they'd be shown to disagree on pretty much everything.[/quote] Jedd, I can't imagine a member-based application that doesn't require an email address (pretty vital for password recovery, etc.). Putting it in the session on the other hand probably isn't necessary, and now that you raise the point I'll probably remove it. I completely agree with the latter part of your statement. Most libraries include many edge cases, which are important to the author, and no one else, which is exactly why I'm trying to keep this as minimal/abstract as possible. I would propose that email is a field that the vast majority of developers would require.
[eluser]jayrulez[/eluser]
[quote author="thody" date="1250277586"]@jayrulez: Good call. Especially important, since I'll be adding the ability to store additional meta data for users. One universal get_attr method would be nice.[/quote] yup. I also think your library is doing more than necessary like creating a user. If you're interested i can send you an auth module which in my opinion is ideal for anyone as it is not restrictive and easily extendable. I think you could learn from it.
[eluser]thody[/eluser]
[quote author="jayrulez" date="1250279505"]yup. I also think your library is doing more than necessary like creating a user. If you're interested i can send you an auth module which in my opinion is ideal for anyone as it is not restrictive and easily extendable. I think you could learn from it.[/quote] I think the basics of creating a user is common functionality, which should be included. The full registration procedure is app specific though obviously and will be left out. Would love to see your auth module. If you have a link, post it here, or you can grab my email (js obfuscated) from the sidebar on my site www.adamthody.com.
[eluser]jayrulez[/eluser]
[quote author="thody" date="1250280165"][quote author="jayrulez" date="1250279505"]yup. I also think your library is doing more than necessary like creating a user. If you're interested i can send you an auth module which in my opinion is ideal for anyone as it is not restrictive and easily extendable. I think you could learn from it.[/quote] I think the basics of creating a user is common functionality, which should be included. The full registration procedure is app specific though obviously and will be left out. Would love to see your auth module. If you have a link, post it here, or you can grab my email (js obfuscated) from the sidebar on my site www.adamthody.com.[/quote] hehe it's not my auth module, i just use it. i just sent it to you in an email.
[eluser]jedd[/eluser]
Devil's advocate stuff. I probably wouldn't write a system that didn't require a user to have an email address (though I have, in the past). This doesn't mean we should assume everyone has, and needs, one though. In any case, my biggest problem was clutter in session data - there's not much space in there, and for some people it'll also present a performance concern. I don't like storing arrays in session data, either. (I'm not being contrary, but these are all just more examples of how this kind of library is going to have to make architecture decisions that'll each alienate 50% of its userbase.) With mail address - at least do a test if it exists (I'm happy to code that in and re-submit -- if nothing else, out of this, I'm learning about git -- something I'd been putting off for ages). With my own system, a mail address retrieval method is something I provide in my member model - and 'self' is just another case (rather than having two ways of getting a member's email address - which I think is a bit inelegant). In my experience, the need to know your own email address is rare - it's usually 'someone else' (say when a forum message is posted to a thread you're watching, there's a private message sent to you, etc) - much like needing to know your own mobile phone number in real life. 
[eluser]Rick Jolly[/eluser]
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.
[eluser]Circuitbomb[/eluser]
Storing email in a session is application specific, because you have to consider what the uses of having such a string in the session will be used for in the first place. An extra unique variable (md5()email), would help decrease the chances of some attack vectors such as request forgery if it was used as a hidden user specific unique key in form submissions. 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. 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. As with what thody stated, I couldn't imagine a member system which did not require an email address. The applications for that information simply cover a wide array of usefulness (password recovery, newsletters, verification, and an additional unique identifier in the database). Unless the system had no need to use it, then of course it would be omitted. |
| Welcome Guest, Not a member yet? Register Sign In |
