Core Auth Library

[eluser]thody[/eluser]
Roughed one out here: http://github.com/thody/User-Library/tree/master There's also a unit test controller in the downloads section. Feel free to contribute.

P.S. New to writing open source stuff, pardon me if I've overlooked any conventions.

[eluser]skunkbad[/eluser]
I've got a fully working auth system. I've got a couple of reasons why I haven't shared it yet, and perhaps one of them is important enough to not have a core auth system in CI. This doesn't mean that at some point I won't share my auth system, but I'm still thinking it over.

1) My authentication system uses plain php $_SESSION. Not turning this into a CI Session vs. $_SESSION debate, but the CI community might frown if I shared such a thing. It would surely curdle the stomachs of the CI elite.

2) This is the important reason why Auth must be personal. Open source stuff gets hacked. Name an open source forum, CMS, shopping cart, or blog that hasn't been hacked. They've all been hacked, and you see this on their forums all the time. Making the code available means some evil people are sure to scrutinize its every line, looking for a way to own you. If they know you are using CI, and they know that the CI auth has a vulnerability, they will take you down. Keeping your auth private means the chances of getting hacked are way smaller.

[eluser]thody[/eluser]
[quote author="skunkbad" date="1250136724"]
2) This is the important reason why Auth must be personal. Open source stuff gets hacked. Name an open source forum, CMS, shopping cart, or blog that hasn't been hacked. They've all been hacked, and you see this on their forums all the time. Making the code available means some evil people are sure to scrutinize its every line, looking for a way to own you. If they know you are using CI, and they know that the CI auth has a vulnerability, they will take you down. Keeping your auth private means the chances of getting hacked are way smaller.[/quote]

This is a pretty pesimistic view. Public scrutiny is what increases the security of public auth libraries, not decreases it. Sure, initially it will expose obvious holes, but doing so will help them get fixed. I'd rather have my code vetted so I can make it more secure than to go with the ignorance is bliss model.

[eluser]Circuitbomb[/eluser]
[quote author="thody" date="1250139672"][quote author="skunkbad" date="1250136724"]
2) This is the important reason why Auth must be personal. Open source stuff gets hacked. Name an open source forum, CMS, shopping cart, or blog that hasn't been hacked. They've all been hacked, and you see this on their forums all the time. Making the code available means some evil people are sure to scrutinize its every line, looking for a way to own you. If they know you are using CI, and they know that the CI auth has a vulnerability, they will take you down. Keeping your auth private means the chances of getting hacked are way smaller.[/quote]

This is a pretty pesimistic view. Public scrutiny is what increases the security of public auth libraries, not decreases it. Sure, initially it will expose obvious holes, but doing so will help them get fixed. I'd rather have my code vetted so I can make it more secure than to go with the ignorance is bliss model.[/quote]

This really only depends on the disclosure and the ethics of the person(s) who find vulnerabilities in software. Not everyone who pen-tests applications adhere to full disclosure, some publicly post vulnerabilities within loose circles, and by the time the flaw reaches the developer, damage has been dealt.

However, in my personal opinion, keeping your code propriatary means that you, or your team has to scrutinize each line, all the time. Allowing your code to be publicly available allows hundreds, perhaps thousands or fresh eyes to poor over it, increasing the chances of a security flaw being disclosed properly, and fixed faster.

@skunkbad CMS's come in all shapes and colors, some have names and some don't. It can be said that no developer writes perfect code, and that is true, but to say that every CMS/webapp has been hacked is only speculation.

[eluser]skunkbad[/eluser]
thody, Circuitbomb,

While we have our opinions, I could think of some other reasons that CI may want to avoid adding an auth class, and these too would just be opinions. The fact that an auth class, or any hint of an auth class, is not found in the SVN should indicate that we are going to have to write our own, and hope for a community that keeps producing auth choices. You'll see my auth someday, and until then, maybe you can build one to share with me!

[eluser]Circuitbomb[/eluser]
or as a community we could just pull our collective knowledge and develop a fresh, flexible, open source, auth library which integrates easily with CI.

Or get involved with one that already exists.

[eluser]thody[/eluser]
[quote author="Circuitbomb" date="1250147712"]or as a community we could just pull our collective knowledge and develop a fresh, flexible, open source, auth library which integrates easily with CI.

Or get involved with one that already exists.[/quote]

Bingo. I'm game. My vote would be starting fresh since my biggest beef with existing attempts is bloat.

Here's a start:
http://github.com/thody/User-Library/tree/master

[eluser]jpi[/eluser]
Hi,

A few feedback regarding you auth library :

create method :
what if $user['password'] isn't set ? You should trigger an error or a warning
You should check that each key in array $user is a valid field in the DB table user

get_user_id method : it should return an int not a string
delete method : if identifier is username, as your DB scheme is not UNIQUE for the field username, this method could delete several users...
login method : $username could possibly be NULL but the first line of this method is a call _test_user_credentials where $username shouldn't be NULL. That's not consistent.
_set_persistent_session : you use a custom cookie. It does not store the IP adresse or at least the user agent. Cookies can be stolen.

Regarding your SQL table. Why is `id` an int(11) ? Do you expect billions of users ? It should also be unsigned. password whould be a varchar(40) because dohash use sha1.

A lot to correct, but you really should think when you are coding "what I want this method to do but also what i dont want it to do and what could someone use it to do something unexpected". Also keep writing a lot of unit test, that's cool

[eluser]thody[/eluser]
[quote author="jpi" date="1250258195"]Hi,

A few feedback regarding you auth library :

create method :
what if $user['password'] isn't set ? You should trigger an error or a warning
You should check that each key in array $user is a valid field in the DB table user

get_user_id method : it should return an int not a string
delete method : if identifier is username, as your DB scheme is not UNIQUE for the field username, this method could delete several users...
login method : $username could possibly be NULL but the first line of this method is a call _test_user_credentials where $username shouldn't be NULL. That's not consistent.
_set_persistent_session : you use a custom cookie. It does not store the IP adresse or at least the user agent. Cookies can be stolen.

Regarding your SQL table. Why is `id` an int(11) ? Do you expect billions of users ? It should also be unsigned. password whould be a varchar(40) because dohash use sha1.

A lot to correct, but you really should think when you are coding "what I want this method to do but also what i dont want it to do and what could someone use it to do something unexpected". Also keep writing a lot of unit test, that's cool [/quote]

Hey jpi, really appreciate the feedback, you're right on with your observations. What you're seeing there is really just a couple hours of work, more or less a proof of concept, and has a long way to go obviously. At this point the goal has essentially been "make it work", and now that the core functionality is there, I'll be going back and tidying things up.

Feel free to fork the project and contribute, or keep posting issues here or on the issues tab in GitHub. Any help is appreciated.

Cheers,
Adam

[eluser]jayrulez[/eluser]
Hello there Thody, please allow me to start beefing with your auth library.

I think you can make it less worded by having things like these in 1 method

Code:

function get_username()
        {
            $user = $this->CI->session->userdata('user');
            return $user['username'];
        }

    // --------------------------------------------------------------------

    /**
        * Gets user_id from session
        *
        * @access public
        * @return int
        */
        function get_user_id()
        {
            $user = $this->CI->session->userdata('user');
            return $user['user_id'];
        }

    // --------------------------------------------------------------------

    /**
        * Gets email from session
        *
        * @access public
        * @return string
        */
        function get_email()
        {
            $user = $this->CI->session->userdata('user');
            return $user['email'];
        }

like

Code:

function get_attr($name)
        {
            $attrs = $this->CI->session->userdata('user');
            return isset($attrs[$name]) ? $attrs[$name] : null;
        }

get_attr("email");
get_attr("username");
get_attr("user_id");