CodeIgniter Forums

Full Version: Writing Admin/User/Public controllers to insure authentication
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4
To answer the question at the beginning of step 4 in your tutorial:
Quote:This one gave me a lot of trouble, not knowing where the problem was when I used the ‘composer_autoload’ parameter set to true in the config.php file (I still don’t know where the problem is… so please feel free to tell me).

Line numbers below may be approximate, depending on changes over time, but I referenced https://github.com/bcit-ci/CodeIgniter/b...gniter.php

In system/core/CodeIgniter.php your controller is probably loaded somewhere between lines 385 and 460. The check against the composer_autoload config value and the loading of the autoload file occurs after this, between lines 467 and 477.

The controller isn't instantiated until line 494, but PHP tried to resolve the class name when the controller's file was loaded and couldn't, because Composer's autoloader wasn't available, yet.

For most files, loading Composer at this point is fine. For your base controller, though, you have to load Composer earlier.
Hm, within the bootstrap file Composer loader is called after controller instantiation.

1.

In this case CodeIgniter.php might be faked with a custom version, sorry about that.
https://github.com/bcit-ci/CodeIgniter/c...nt-6985684

Copy system/code/CodeIgniter.php within application/core/

In index.php make a replacement

Code:
require_once APPPATH.'core/CodeIgniter.php';

Edit the copied file CodeIgniter.php and move Composer activation code before the controller instantiation.

2.

The cleaner way is asking in GitHub this modification (moving the Composer code fragment) to be done within the original file CodeIgniter.php.


Edit: Not "controller instabtiation", "loading controller files", my bad.
That would get a little too complex in my opinion. Instead of just requiring the composer autoloader inside the index we would have to move a file from system/core to application/core and then make the require in index.php. That would still be a hack Smile.

My decision was to just put the vendor directory inside the application, and do a require_once() of the autoloader inside the config.php file just after the $config['composer_autoload']=FALSE;

This way, if in the future the core files of the CodeIgniter will change the way the composer is used, I just look in the config.php, change the composer_autoload parameter to TRUE and delete the line that required the autoloader.
I hack CodeIgniter.php for other reasons anyway.
@Avenirer Agreed, what you propose is a solution too.
OK I have finally got around to handling sessions in my controllers. I see that session->set_userdata() stores information in a cookie on the user's machine. I know you can encrypt your cookies, but I am reluctant to store sensitive data or values that could be manipulated by a malicious user in this fashion. I am accustomed to storing ONLY a session ID in the cookie and storing information related to that session ID on the server (where it cannot be directly manipulated by the client.

Is there some way to make sure that the session contents are stored on the server and only the session ID is stored in the user cookie?
OK I've been experimenting a bit and apparently if you set $config["sess_use_database"] to TRUE then values that you set using $this->session->set_userdata() will be stored in the session table on the server rather than in a cookie on the user's machine.
Hello sneakyimp,

If you look in the config.php file, you will find there

$config['sess_driver'] = 'native';

Maybe yours is set to cookie instead of native?
Also a lot of settings are made in there.
Thanks for your response. It was in fact set to cookie at first -- that doesn't seem very safe to me! I now have it set to database.

I'm guessing that 'native' means that the PHP server will use the default php session-handling functionality that stores session data in the /tmp folder as flat files. It's my understanding that this can contribute to performance problems when the server gets busy.
Well... every choice in life has costs...
Pages: 1 2 3 4