Could session_start() in php be messing up my users sessions lengths? - php

My php.ini file is set to expire sessions within 24 hours. But my users complain after being logged out after just 20 minutes or so.
I use session_start at the beginning of every page. Could that be messing things up for me?
Or could there be anything else causing this?
Just realized I might be on a shared hosting. And it might have some group settings for garbage collection with sessions. Anyone know how to look into this or set mine to be more specific?
Thanks!

Check phpinfo() to see what the settings really are. PHP has multiple .ini files, and its settings can be overridden in multiple places, so your session session may not be the ones actually in effect. phpinfo's output will show what the "Local" this-is-now-whats-in-effect settings are.
Beyond that, session_start() won't delete a session itself, but it MAY trigger a session garbage collector run based on a few gc_* .ini settings. It's a probabilistic thing, though, and won't happen every time you start a session.
Another possibility is that your session files are going into a system temp directory somewhere, and something external to PHP is cleaning up that directory at 20 minute intervals. So check what the session.save_path setting is and see if anything's cleaning up that location.

ini_set('session.gc_maxlifetime',28800); #28800 - just an example time - set your own
ini_set('session.gc_probability',1);
ini_set('session.gc_divisor',1);
session_save_path('/path to your sessions folder');
ob_start();
session_start();
You do need to create a session folder first.
This works for sure on GoDaddy shared hosting.
On VPS you can use this or just update your php.ini file.

Related

How to clear TMP folder using PHP (PHP Sessions)

I have a folder named "tmp" in my webserver, it contains 237 files.
Title is something like this sess_1at4ka9r77f0f4n4ijldv561d1 and it contains data something like this FBRLH_state|s:32:"183047584cfac9ca4353c21535caa39d";
All files were last modified on 06/08/2018 (today). But the thing is
I think it contain PHP session data.
I use this code to create php sessions
ini_set('session.gc_maxlifetime', 86400 * 90);
session_start();
Now this is a bit confusing. only 12 people visited my website today. But why there are 237 session files?
Did i wrote some bad code? How can I minimize tmp folder size?
Nothing in the code you've shared states whether your session files will be eventually removed or not. That code only says that, if garbage collection is triggered as a result of this script's execution, only files older than that will be removed.
Whether current script will launch session clean-up and how often it'll happen is determined by the runtime values of these directives:
session.gc_probability
session.gc_divisor
(All this, assuming you haven't fiddled with session.save_handler to implement a custom mechanism, in which case your custom code should take care of handling data removal properly.)
As about the 237 files, I presume it's the default shared directory where all PHP scripts store sessions by default—but of course it's just a guess (I don't even know their modification time).

PHP session_id changes between pages or when refreshing the page

The problem is that every time I refresh the page or when I change the page to another one, the session_id changes and new session file is created in session_save_path.
Here is the initial part of my code:
<?php
session_start();
echo session_id();
...
?>
Obviously the session variables (which is the thing that I need) don't work.
A curious thing is that the page works fine on localhost but doesn't work when I try it on the server.
Thanks in advance.
Check this setting in your server: session.auto_start
This will cause session to be autostarted in each page whether you call session_start() or not.
Make sure that there are no phantom CRLFs or such stuff before session starts. In production the error_reporting can be off so it might not get caught, but the session might find difficulty getting written. This can sometimes cause this.
On your server, in php.ini check TTL for your cookies. session.cookie_lifetime defines how long the cookie will last in seconds (default is 0, which means until the browser is closed) and session.gc_maxlifetime defines how long before the data is deleted, also in seconds.
And make sure the session file isn't stored in a /tmp folder.
Looks like your directory with sessions is not writable.
That's why php generates a new session file each time.
Check your chmod for sessions folder.

session variable value changed

I am using session to store some data in my php website, but in some page when I fetched the data in the session is changed some times and some time its same.
I searched lots of and find some answer at
session id value changes
" if you have register globals on, you may be seeing behavior like that if you use the variable $id in your code. As a test, try:
<?php
session_start();
$_SESSION['testing'] = 'Foo';
$testing = 'bar';
die($_SESSION['testing']);
?>
"
help me i searched in my php file but i dont find similar variables like session variables so what is the problem ??
give me some details about php session and if possible suggest good books.
edited :
i have set the php.ini as all of you saying its problem of register_global off and than ckeck by using phpinfo(); function and check the register_global is off.
but after some time i logged in with my id and than at mypage menu.php accessed by me after that its changed session logged id and i logged in another account automatically.
please help me
Disabling Register_Globals by adding the following line in your php.ini file may fix this problem.
register_globals = Off
If you are using a Shared Web Hosting service, follow:
If you have access to /cgi-bin folder then create your custom php.ini file inside it.
And if you dont have access, then create your custom php.ini file in root folder.
And then add above mentioned line in php.ini file.
Adding the following line of code in your .htaccess file also fix your problem.
php_flag register_globals off
You shouldn't be using register globals so it shouldn't be an issue.
Add this line to .htaccess to disable if you have register globals running:
php_flag register_globals off
it can't be done with ini_set() at runtime so you will need to use htaccess or php.ini as in previous answer.
It's unlikely these days that register_globals is your problem. More likely it's to do with a) where the actual session data is being stored; and b) how the "session ID" is being transmitted from one request to the next.
The first thing to look at is session_save_path(), which tells PHP where on disk to store the data that you put into the session variables.
The other part is a little more complicated, but is about how the cookie is set which lets PHP know to load the same session rather than creating a new one. You might need to look at things like the lifetime of this cookie, or the scope (domain / sub-domain / URL path) it applies to. Have a look at session_set_cookie_params(), and in general have a read through that section of the PHP manual to understand how sessions work.

php manually session.gc_maxlifetime under Linux (Debian,Ubuntu) ignored. How to set alternative?

My Problem is quickly described by the need to extend the session data life over it's default settings within the php.ini without changing the php.ini. I am looking for a solution that can be applied to a number of different php setups across server platforms so there is no need for the script to be changed for every install.
Since I don't want to change defaults on my server and want to stay as independent as possible with my script I am looking for a way to exceed the default 1440 seconds that are set for the garbage collector to dispose of my session data prematurely.
Simply setting ini_set('session.gc_maxlifetime',36000);
to 10 hours will not work as on some servers the GC will run unaffected by php's settings and delete my sessions after 24min anyway as described here.
To get around this problem the author suggests to change the session.save_path to another folder unaffected by the os's gc and thereby enforcing the set session.gc_maxlifetime to my settings.
Unfortunately I was unable to create a temp folder within php's tmp space and though I like to I don't seem to be able to since I don't have 0600 access on most servers.
One solution would be to link my session data to my own folder created right in my shared host folder but that seems insecure as this folder must then be available online and therefor exposed to possible id theft.
Though I do not know whether that is the case.
Another solution would be to include $_SESSION["stayalaive"]=time(); since the gc only deletes sessions untouched for the specific amount of time to the login script so that the session will be extended every time the login script is called though that means if the user does not click anything for 24min the session will be deleted anyway which is something I could possibly live with but it also seems to put on another process that seems unnecessary.
So my question is how to set up my session data to stay alive for 10 hours without clocking too much performance for it.
I have used php.ini directives inside scripts before and besides you can make directories inside your hosting reserved space.
So (at the very beginning of your script) this must be work, no doubt:
<?php
// obtain current directory
$APPPATH = dirname(__FILE__);
if ( ! file_exists($APPPATH . '/tmp/sessions'))
{
mkdir($APPPATH . '/tmp/sessions', 0700, TRUE);
}
ini_set('session.save_path', $APPPATH . '/tmp/sessions');
ini_set('session.gc_maxlifetime', 36000);
session_start();
?>
Both directives have PHP_INI_ALL changeable mode, so can be set inside scripts.
Any webhost worth their salt will give you a directory above your public_html (or whatever) folder. If yours does, then you can create a directory for sessions there, and it won't be accessible from the web.
If your hosting is so crappy that anything you're allowed to touch via FTP/SSH/whatever is also available via HTTP, things are more annoying.
So assuming you have a crappy host, here are a few ideas:
1) Store sessions inside your web root, and use .htaccess to make it non-browsable.
2) Store session data in the database.
Either of those options should enable you to set your own garbage-collection rules via ini-set(), and avoid having other processes clobber your sessions.

nginx / php / php-fpm | Problem with storing cookies

Greetings.
I am right now in the middle of reinstalling my whole dedicated server. I went with
-Ubuntu Server 10.10
-PHP 5.3.3.1
-php-fpm
-nginx
Now, almost everything seems to work, though there remains one problem with the sessions. No matter what I do, the sessions doesn't seem to store themselves properly (and they did on the previous setup).
The base application is phpBB board. When I login, it's okay - though it appends additional SID parameter to all of the URLs.
forum/index.php?sid=f506ccd42065322f61cb56fc6df6557a
You can navigate around the forums without problem, though if you delete the SID parameter, you get logged out. I thought, that perhaps the sessions aren't stored in cookies, but in URLs, but php configuration seems fine.
The same occurs with phpMyAdmin - I also get logged out, when I delete the token parameter.
In the meantime, it seems the cookies are getting created anyway, it's like they aren't used, or are getting deleted immediately.
I am getting more and more frustrated with that, maybe someone has an idea on how to troubleshoot that? I will post any configuration files necessary.
I thought maybe it's the problem with suhosin (it wasn't installed on the previous setup), but I have no clue. The PHP config is out-of-the box atm, I only modified nginx config.
The various session cookie parameters are all documented here.
In particular, check the "session.use_cookies", "session.use_only_cookies", and "session.trans_sid" settings. If PHP can't succesfully create a cookie, it'll fall back to the trans_sid method (which is what you're seeeing: the session ID being passed around as a query/form variable).
You can trivially check if any cookie-related headers are going out by using Firebug and HTTPFox in Firefox. Both let you view the incoming/outgoing headers for requests.
May be some usefull information can be found in PHP-fpm error log? Set parameters in php.ini
error_reporting = E_ALL & ~E_DEPRECATED
log_errors = On
error_log = ;
some file php can write in or "syslog"
Also try to look in nginx error log.
Does PHP-fpm process-owner has write permissions to sessions dir? See session.save_path on php.ini for session dir
See if your session_path is correct and has the right permissions. That fixed my problem.
Also, be mindful of the user and group of the processes, as this will effect the default permissions that the session files are created with. If set to default, it may create as root, and then not be able to be read the next time the session file is accessed.
Look for Unix user/group of processes in your php-fpm.conf
and set both user and group to php-fpm

Categories