Login System - Code Igniter just makes things excessively complex..

[eluser]tomclowes[/eluser]
Perfect ! Thanks so much everyone.

Apologies for rolling off the questions - the documentation is good, simply not in depth.

Sessions. I am aware of the session database system in place. My impression is that if you set up a db (like the one suggested), CI will automatically update it etc when it comes to sessions.

My system requirements are somewhat different. I have a user table, and a column entitled session.
On logging in I am updating this column with the session.

I am however having problems $config['sess_time_to_update'] = 300;

Could someone elaborate on what the point of reloading session IDs? It simply makes my job more complex.
As such I was going to simply make it the same as my session time I.E it never gets reloaded.

Hopefully this is my last question - at least on user authentication.

Cheers - this is a great community.

[eluser]WanWizard[/eluser]
You shouldn't store the session id anywhere, as it changes regularly for security reasons.

Do it the other way around: when a user logs in, store the user_id (any maybe some other attributes) in the session. In your is_logged_in() method, check if this session variable exists, and if so, load the user from the database and return TRUE. When the user logs out, remove the user attributes from the session record and is_logged_in() will return FALSE;

Some people choose to destroy the session when the user logs out, but that's not my thing, as it deletes other session items that might have to survive a logout/login (for example a language preference).

[eluser]pickupman[/eluser]
Wanwizard has a good point. Plus, use the built in session class/db...don't fight it. The time to update is a variable set to do garbage collection. Rather than cleanup old sessions on every page request, it is handled by this time increment. The thought is that most users want to use DB stored sessions (recommended) for security reasons. This is a DB a query that not run everytime for speed reasons.

[eluser]nuwanda[/eluser]
I just have a helper that checks for login status. Autoload the helper.

Code:

<div id='nav'>
&lt;?php

if(is_logged_in())
{
  if(is_admin())
  {
    echo anchor('admin','Admin Dashboard');
  }

  echo anchor('user/logout','Logout');
  echo anchor('users/profile','Profile' . '&nbsp;[' . $_SESSION['user_name'] . ']');

}
else
{
    echo anchor('user/login','Login');
    echo anchor('user/signup','Signup');                        
}

echo '&nbsp;' . anchor(base_url(),'Home');
?&gt;

</div>&lt;!--end nav--&gt;

[eluser]stormbytes[/eluser]
I always hated the "MY_controller" convention for such basic functionality. There should be a login class buit-in to CodeIgniter. How the development team would force users to tap dance around such an obvious oversight is mind boggling.

FWIW: I created a 'login' library which is autoloaded. User logged-in checks are done in constructor method, and any required user vars are made available via $CI->load->vars().

I find this infinitely easier then having to remember to use MY_Controller.

[eluser]InsiteFX[/eluser]
Did you know that you do not have to call it MY_Controller it just has to be saved as MY_Controller!

The Class name can be anything as long as you save it as a MY_Controller

Code:

Class Backend extends CI_Controller {

    public __construct()
    {
        parent::__construct();
    }
}

Now save it as a MY_Controller.php

InsiteFX

[eluser]stormbytes[/eluser]
If I understand you correctly, MY_Controller (in application/core) will automatically extend CI_Controller, and any subsequent controllers will be spawned from MY_Controller even though the controller is written as "class Login extends CI_Controller".

If that's what you meant, then no, I didn't know that.

[eluser]stormbytes[/eluser]
And if that is in fact true, then you saved me about half a day futzing around with Hooks!

[eluser]InsiteFX[/eluser]
It's true and it is not documented!

Example:
Saveas - application/core/MY_Controller.php

Code:

class Application extends CI_Controller {

    public function __construct()
    {
        parent::__construct();
    }
}

saveas - application/controllers/home.php

Code:

class Home extends Application {

    public __construct()
    {
        parent::__construct();
    }
}

The important thing is the the file is saved as MY_Controller.php

You will need the config autoload in application/config/config.php

I learned this from Adam Griffins a long time ago.

InsiteFX

[eluser]stormbytes[/eluser]
I don't see anything new about that. You're creating the "application" controller which, saved as "MY_controller", extends the base controller class. You then create subsequent (ordinary) controllers (saved in app/controllers/) which extend the 'application' controller and NOT the base controller class - even though this extends the base controller class indirectly.

To do this (and rely on it) would mean changing some of my CI bundle functions ™ and workflow. Precisely why I consider this approach impractical. I'll keep hacking away at the hooks!