[Solved] Various Session problems

[eluser]fchristant[/eluser]
@N0xie: I am aware of that thread. I still find this part to be interesting:

"But when an AJAX operation is done (get or post), the session is updated and a new session id is generated (and updated in the database) but the cookie in the browser is not updated, so the next time the browser requests a new page it sends a cookie with the wrong session id and the session becomes invalid resulting in loss of session data (person getting kicked out if logged in)."

I do not know why, but in my case an Ajax call does not generate a new session at all. If I access a page, and no session is there yet, it is created. If on that same page Ajax calls are made, those Ajax calls in my setup do not lead to new session entries. What am I missing, perhaps I misunderstand the problem?

[eluser]WanWizard[/eluser]
Depends on if the code in the path of the ajax call loads the session library. If not, there is no issue. If it does, it will create a new session record.

Note that this is only an issue with database sessions. If you use cookie based sessions (which you shouldn't), there is no issue, since the session_id rotation problem is database related only.

[eluser]fchristant[/eluser]
The code that is called in the Ajax path indeed loads the session. However, so far that does not seem to create new sessions. To be sure, I now applied the IS_AJAX trick anyway, and will monitor how it behaves.

[eluser]bretticus[/eluser]
[quote author="fchristant" date="1282319882"]
I have not yet deployed this code to production because I have made other changes that I need to finish first, but I hope this solves the IP problem as well. Now that I think of it, I think it will, because I am figuring that it was the cronjob "sessions" which had an ip of 0.0.0.0, which makes sense, since they run on the same host.[/quote]

It's worth noting that the ip_address() method of the input class checks for the typical web server headers. If none yield an IP, the ip is set to '0.0.0.0'. So, yes, if you are executing PHP directly (cron or bash, etc.) those headers will not be found and CI will return '0.0.0.0' You might try adding some logic to disable sessions when '0.0.0.0' is encountered. Or you can go a bit further and use the php_sapi_name function to detect CLI usage and disable sessions somehow (I'll leave that thought exercise to you.)

[eluser]fchristant[/eluser]
@bretticus: Since the cron jobs now use a controller that does not extend my base controller, and thus does not load a session, there is no need for me to validate the IP address anymore.

I do use php_sapi_name for another reason, when it returns "cli" the relative path needed to load the CI system and application dirs is different, since no web server is involved.

[eluser]bretticus[/eluser]
Just curious. How do you invoke a controller from command line? Are you using an http host like wget or cURL? If so, I guess php_sapi_name is irrelevant anyway.

[eluser]fchristant[/eluser]
@bretticus: For each cron job I have a seperate php file. These files are basically copies of the CI index.php, yet is slightly tweaked in order to make it work when run from the command line:

/* Call our controller/method */
$_GET = ''; // IMPORTANT - REQUIRED for proper url
$_SERVER['PATH_INFO'] = "services/imagedelete";
$_SERVER['QUERY_STRING'] = 'services/imagedelete';
$_SERVER['REQUEST_URI'] = 'services/imagedelete'; /* Emulate the URI manually */

It is a trick really. I am simply manually setting some server vars that CI relies on in order to function. It works beautifully, I can use all of the good stuff of CI in my cron jobs

[eluser]bretticus[/eluser]
[quote author="fchristant" date="1282346037"]I am simply manually setting some server vars that CI relies on in order to function. It works beautifully, I can use all of the good stuff of CI in my cron jobs [/quote]

Ah, good for you. Nice hack! You just set the globals arrays. I'll keep that in mind for a quick CLI fix down the road.

Have you looked at Phil Sturgeon's MY_URI class?

[eluser]Unknown[/eluser]
You can use wget,curl or links to invoke a controller from command line.

[eluser]fchristant[/eluser]
Thanks for the additional CLI solutions. I haven't looked at MY_URI yet but will soon. I do not want to use wget for CLI scripts:

- Serving your crons via a web server produces needless overhead whilst they do not need a web server at all
- Security-wise I do not want my crons to be accessible via a URL (although I know can secure those)
- wget,curl may not always be available or installed, although they usually are