I'm running a WordPress installation on XAMPP. Some files are using sessions, and I notice that any file that has session_start() will load endlessly. I always placed session_start() at the very top of the php files that are using sessions, but it still loads forever. What's up?
Does the page actually load or does it just take a long time? If it never loads, maybe check the logs for errors to write to disk. The session_start() function required apache to write a bit of data. Could it be a permissions issue?
Just search the below line in your php.ini file located at c:\xampp\php\php.ini to fix the issue. Change the value to 1 from 0.
use_only_cookies=1
Related
I didn't change any code, all of a sudden when I visited one of the webpages, I see
Warning: session_start() [function.session-start]: open(..)Failed: File too large .. index.php on line 2.
Another error is:
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent`
Line1 : <?php
Line2 : session_start ();
Questions:
what is the reason for error that tells File too large? what file is large?
why all-of a sudden there is an error without any file modification being done?
why it is throwing 'headers already sent', when there is nothing defined before session_start, not even a space ?
How to fix this issue?
1. what is the reason for error that tells File too large? what file is large?
This seems to be the hosting provider issue, as the original file was never modified, and the webpage has been tried from multiple browsers even after clearing the cache.
When you do session_save_path("../_session1001"); that is mentioned below, you can see that your session is written to that path, so may be that this file was becoming too large in your shared memory,and now that I explicitly mentioned a physical space to write the session files to, this error is no more.
4. How to fix this issue?
Create a directory named say '_session1001' and give chmod 755 so your webserver (app) can write to it.
Add this line before session_start
session_save_path("../_session1001");
Ensure you protect the directory via .htaccess file.
ie:
<?php
session_save_path("../_session1001");
session_start();
Read more here : http://php.net/session_save_path
Note:
Debian does not use the default garbage collector for sessions. Instead, it sets session.gc_probability to zero and it runs a cron job to clean up old session data in the default directory.
As a result, if your site sets a custom location with session_save_path() you also need to set a value for session.gc_probability,
e.g.:
<?php
session_save_path('/home/example.com/sessions');
ini_set('session.gc_probability', 1);
?>
Otherwise, old files in '/home/example.com/sessions' will never get removed!
I was having problems with my PHP website (SuiteCRM) not being able to log users in and I found it was due to not being able to write on the sessions directory.
I am able to fix it by creating the directory /tmp/php_sessions and giving it write permissions for the Apache user www-data. I see the directory get populated with files as users log in.
However, Ubuntu Xenial is deleting my entire tmp directory on reboots, so I have to redo this all over again every time. I decided to move my save_path elsewhere.
After changing things in my php.ini file, and restarting Apache, I can check that they are effective by running this simple script:
<?php
echo ini_get("session.save_path");
phpinfo();
?>
This shows me a double confirmation of the new path, first echoing /var/tmp/php_sessions and then, in the middle of all the phpinfo information, showing the same value as both Local Value and Master value for directive session.save_path.
BUT the directory that php is using is still the first one, /tmp/php_sessions! It seems that my setting is being ignored.
Am I overlooking something? Where could that old setting be buried? Or how can I make the new one effective?
(P.S. - I am not using a redis handler as in another similar SO question)
Ok, I solved my own problem and the general answer is as follows:
There are two more things that can be changing the path and need to be checked,
the PHP code of the application might be changing the ini directive, search the code for ini_set(session.save_path
the PHP code might be using the session_save_path PHP command to override the ini. Search the code for that also (and notice the two underscores _!)
And the specific answer for my case was that SuiteCRM uses session_save_path command to set its path with a value coming from the file config.php found at the web root. That's where I found the old setting, and changing it solved my problem (for good, I hope).
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.
How can i start a session in PHP which will be global to all my pages. I don't have access to the php.ini file. So session.auto_start = 0 in my php.ini will not be a solution for me.
Thanks.
$_SESSION is a global.
Start it off by calling session_start() before any output.
session_start();
Place this at the top of your pages and it will start a session. You can access it and set its variables with $_SESSION['somevalue']. Also you can name the session using session_name("some name");
If you want all pages to automagically have a session_start(), without actually writing the code, you're pretty much stuck with ini-settings. It is very well possible that although you cannot alter php.ini in a shared environment (proper hosters do offer a custom ini IMO), that you can just add the php_flag session.autostart = 1 to an .htaccess file in the root.
Nothing bad in starting a session with session_start() - everyone doing that.
Don't you have some config file already, which being included into every script on the site? If yes - why not to put session_start there? If not - you have to think of having one.
I have a problem where i am losing the PHP session between 2 pages.
The session_start() is included in a file called session-inc.php into every page requiring a session to be set. This works for all pages on the site except one particular page, member-profile.php. When this page is visited a new session with a different id (same session name) is set and used instead.
A few more details:
Session name is set manually
All pages are on the same server under the same domain name
If i put an additional session_start() above the include('session-inc.php') in the member-profile.php file, the session is carried over correctly
I have tried setting the session_cookie_domain and session.session_name in the .htaccess, this worked for this domain but it stopped the session being passed over to out payment domain
We are running apache 2.2.6 with php 5.2.5
Putting the session_start() above the include('session-inc.php') in the member-profile.php file is the quick and dirty fix for this problem, but i am wondering if anybody know why this would be happening.
Cheers
Will
According to PHP documentation, session_start must be called before any output is sent back to the browser-- could this page have a rogue CR/LF, Unicode byte-order mark or similar that is causing output before you include('session-inc.php')?
While migrating a legacy site from PHP4 to PHP5 I noticed a php.ini configuration setting that causes php to auto-start the session upon every request. It's an alternative to placing session_start() onto every page...
There are multiple ways to enable this setting:
Put the following line into php.ini:
session.auto_start = on
or put this into your apache virtual-site config or .htaccess file:
<IfModule mod_php5.c>
php_flag session.auto_start on
</IfModule>
and it should make $_SESSION changes available across all pages
I have just encountered this problem. Interestingly, browsing via http://127.0.0.1 instead of http://localhost helped me.
I just spent all day diagnosing this issue in my Ionic3 - to - PHP project. TL; DR - make sure your client is actually sending session credentials.
In the interest of helping anyone who makes this mistake, I will share how I found the problem.
I used these tools to diagnose the session on both the client and server:
1) Add a test file with phpinfo() to the server to review PHP session options.
2) Review the PHP code to make sure that no output, intentional or un-intentional occurs before the session_start() line. Check the status bar of Visual Studio Code to make sure the Byte Order Mark (BOM) is absent from the PHP files.
3) Review server PHP logs (in /var/log/nginx/error.log for me). Add error_log() lines to the php file to dump the session_id() or $_SESSION array.
4) Use tcpdump -An 'port 80 or port 443' to view the actual HTTP requests and replies. (That's where I discovered the missing cookies).
For an Ionic3 data provider the correct syntax for the client is:
var obsHttp = this.http.post(url, body,
{ headers: new HttpHeaders({
'Content-Type':'application/x-www-form-urlencoded'
}),withCredentials: true }).timeout(this.timeoutTime);
Notice the withCrentials:true
One needs to call subscribe on the obsHttp() observable to send the request.
Found the issue
There was a byte order mark at the beginning of the main includes file of the second domain. as stated by ken, cant have any output before a session start, it was not setting the session correctly.
SOLUTION:
session.auto_start = on
in file: php.ini
It solved the issue of re-generating session id on page reload (page refresh / change pages).
The issue appeared after the update of CPanel (and included Multi PHP), even the php version remained the same.
The PHP.ini file didn't had that variable at all.
Went in Cpanel -> MultiPHP INI Editor -> Editor Mode (not Basic, in basic you do not have this setting) and added the line. Press Save.
TIPS / WHEN TO USE THIS SOLUTION:
To determine if that is the problem, put a line at the very beginning and at the very end of your index.php file to check the session id. Use function:
session_id();
Navigate through pages / reload the page. If the session_id value changes the problem is not in your code and this solution should solve your problem (the session is lost outside of your code).
I also tried to verify the availability of saving session on the web server (session.save_path) but, even if it was a lead, it was not the case.
I imagine this is a "feature" of Cpanel with MULTIPHP UPDATE that will happen quite often.
I had this problem, and the cause was that PHP was ignoring all cookies after the first 100. (I asked this question to try to find out why, but so far nobody has figured it out). The browser was sending the PHPSESSID*, but since it was the 110th cookie, PHP was ignoring it.
To figure out if this problem is what's affecting you, use your browser's dev tools to look at the cookies that the browser is sending with the request, and compare that list to the $_COOKIE array in PHP. They should be the same. But if the browser is sending a PHPSESSID*, and there's no PHPSESSID* in $_COOKIE, then that would explain why sessions aren't working.
I solved the problem by not having my site use so many cookies, which is good practice anyway.
*PHPSESSID is the default session name. Your site may use a different name.
To solve the session_id change after each request, you change the parameter session.auto_start and session.cookie_httponly into the php configuration file.
to find the used php configuration file
php -i | grep "php.ini"
then you open it, and try to find the parameter session.auto_start . you set
session.auto_start = 1
session.cookie_httponly = 0
finally you restart your httpd/apache service.
Found the issue
In my case it was due to Varnish Settings please check your varnish settings. PHPSESSID you can exclude the cookie from the Varnish Settings.
I'm not an expert, but found a solution after careful investigation of domain name in the cookies info of two webpages opened on Firefox. (Right click on the page, select inspection and the storage). checked domain names and found that one with www.example.com and the other without www (example.com). changed all the page links to same format and the problem solved for my case.
Found the problem was a byte order mark (BOM) being ouputted at the start of the file. Got rid of it and it sorted out the session problem.