I am facing a problem recently with PHP Sessions, on every browser refresh the sessions are getting lost.
I saw that the PHPSESSID is not being read in the cookies.
Then i tried this piece of code.
echo (isset($_COOKIE['foo']) && $_COOKIE['foo']=='bar') ? 'enabled' : 'disabled';
And it seems that PHP cookies are disabled.
My question is this: How can i enable the PHP cookies? What is causing this problem?
Is it a server configuration?
Thank you in advance. Hope to read an explanation from someone.
There are 2 places to do it, either in your php config, or in an htaccess file.
Config
find and change this setting in your php.ini file:
session.use_cookies=1
heres the docs on this and all the other cookie related switches.
note: if you dont know where youre php.ini file is, from the command line, type $ php --ini and itll show you where its located for the cli, the server version will likely be up one level in an apache2/nginx folder.
htaccess
check you dont have this line in your .htaccess file.
SetEnv session.use_cookies='0';
Related
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).
I am using xampp on chrome in a mac and I can't access phpMyAdmin. I used to get a error on the site, but I changed the session.save_path in the configuration file and it opened put now every time I try to press something it gives me an error saying Error: Token mismatch.
Here is the error I am getting:
Here's a link of the same image: http://ninjas.zxq.net/error
Does anybody know why this is happening?
I found the answer.
Go to your php.ini file in Applications>XAMPP>xamppfiles>etc>php.ini
around line 1507 uncomment the line
;session.save_path = "/tmp"
by removing the semicolon. This worked for me right away.
simply changing the tmp path wasn't enough for me..
verify in your browser that you accept cookies and that adblock etc.. is disabled.
although having said that if you've managed to post to this site all that is probably under control :)
I had the same issue, except none of the answers solved my problem. (Localhost with Xampp on Windows 10, using Chrome.)
After some time I figured out that you have to manually delete browser cookies etc to let it refresh/reset the token.
My problem solution was something different again.
I had a user script that was active on the page. In my case it was a TamperMonkey script, but GreaseMonkey, ViolentMonkey, etc could do the same thing.
As soon as I disabled TamperMonkey, problem solved.
First I disabled TamperMonkey completely, using the Enable/Disable checkbox on the icon, to test the theory in general. Problem went away. So then I identified the specific script that was active on the phpMyAdmin page, and I was able to just disable that one script to solve the problem.
Note that the problem script did not in any way modify the phpMyAdmin page - I reduced it to a literally empty script that was loaded onto every webpage. However, just loading itself (an empty, do-nothing script) onto the phpMyAdmin page enough to cause the problem.
Find your php.ini (php -i|grep php.ini) if nginx edit /etc/php5/fpm/php.ini if fpm used.
Uncomment ;session.save_path ="/tmp"
Restart apache or if you use nginx - /etc/init.d/php5-fpm restart
Check /tmp directory to make sure sessions are getting saved there. if you see something like "sess_h820h8ja6pl4bhdmqflngeui23" then your are done.
The problem I am having is that I can not log on to my newly created wiki that I made using MediaWiki. I have searched the web for an answer, and the ones I found did not help with this specific issue (like this one: problem with mediawiki cookies) I have tried with multiple browsers and changed the setting to make sure that cookies are enabled, but I keep getting the same error:
"Wiki uses cookies to log in users. You have cookies disabled. Please enable them and try again."
I'm not sure whether this is a problem with my current version of PHP, which is currently 5.3, or a setting in my wiki.
I found a fix, I'll put it in steps:
Open LocalSettings.php
Go to the bottom of the page, and enter in the following code: session_save_path("tmp");
Create a directory called tmp in the folder where you have MediaWiki installed.
If you are using NGINX + PHP-FPM the previous answers will likely not solve your problem.
From my experience, this issue is caused when php-fpm doesn't have write access to the cookie_path. You can find this path by running:
php-fpm -i|grep --color cookie_path
See what your cookie_path is, then stat the folder and ensure your php-fpm user has write access to it.
To resolve this issue using Nginx and Php-Fpm, I had to change my cookie_path from it's default of / (seriously, why would this be a default?) to /tmp.
After restarting nginx and php-fpm, it works perfectly.
The easiest solution, also recommended by Aaron Schulz, is generally to set
$wgSessionsInObjectCache = true;
$wgMainCacheType = CACHE_ANYTHING;
in your LocalSettings.php. In recent PHP you'll have OPcache enabled by default; if no accelerator is available, at worst this configuration will use the database.
See also cache documentation.
I also had this issue ...
All my browsers were complaining about cookies being turned off....
I thouhgt a group policy had been implemented to disable cookies.
After conferring with my server support team that nothing as such had been implemented I decided to remote to the server.
The server was complaining about low disk space.
I cleaned up the disk by deleting some old unrelated files.
Tried to logon again from my browser and all was Ok.
One answer which hasn't been mentioned here - make sure your file system isn't out of space.
same thing may happen when memcached is used to store session files. in this case wiki will be unable to write cookies neither in / neither in /tmp. if you see in error.log something like
"file not found (11211:9001/qweqweqweqweqe)" this will mean, that you have memchached installed and configured and you need to append the following lines in LocalSettings.php:
$wgMainCacheType = CACHE_MEMCACHED;
$wgParserCacheType = CACHE_MEMCACHED; # optional
$wgMessageCacheType = CACHE_MEMCACHED; # optional
$wgMemCachedServers = array( "127.0.0.1:11211" );
$wgSessionsInMemcached = true; # optional
Just ran into this issue on a Win2008 R2 server running IIS,
when creating a user gave this (red) msg:
Account creation error The user account was not created, as we could
not confirm its source. Ensure you have cookies enabled, reload this
page and try again.
Also if a user tried to log into the Wiki, they would get this (red) msg:
Login error (WikiName) uses cookies to log in users. You have cookies
disabled. Please enable them and try again.
Failed attempts:
I tried JesseG17's solution, but could not save changes to the
localsettings.php file (despite stopping the server).
I checked permissions on the temp location, but that didn't help.
I changed tried changing the temp location via IIS's PHP manager, but
that didn't change anything.
What finally did work was to use IIS's PHP manager to change the
MediaWiki's PHP settings; session.use_cookies from 0 to 1
This solved the problem without any reboot.
Be root:
su -
Then edit the php.ini file:
nano /etc/php5/apache2/php.ini
And set those variables to /tmp:
session.save_path = "/tmp"
session.cookie_path = "/tmp"
You can also correct the permissions just in case:
chmod -R 1777 /tmp
I'm adding a new answer because my setup was slightly different, and the steps I took were similar but not identical to everyone else's.
I installed MediaWiki on CentOS with NGINX. After running it successfully for a few months, I started to get the same cookie error out of nowhere.
The issue I had was that the php-fpm user lacked access to the session.save_path folder. I don't know why it happened, but here's now I fixed it.
I ran a variation of SprintCycle's command to identify where the sessions were stored:
php-fpm -i|grep --color save_path
In my case, it was /var/lib/php/session.
Then I changed directories and set permissions:
cd /var/lib/php
chmod -R 1777 session
I restarted the services, and everything worked again.
service nginx restart
service php-fpm restart
Another thing to check is if your session tmp directory is full. Symptoms are "write failed" messages in your http server error log. Duh!
I had to uncomment the wgCookieSecure setting in LocalSettings.php:
#$wgCookieSecure=true;
only found this after having checked that another wiki on the same computer ran just fine with similar settings. So to debug you might want to install a fresh mediawiki in a neighbour directory and check whether that gives you any trouble. Then you can go thru all the suggestions here as well as the one at
https://www.mediawiki.org/wiki/Topic:Rg3w5u0e70fs8l4e
Put
$wgDisableCookieCheck = true;
in your LocalSettings.php.
(source)
I have been trying to debug this problem for hours but couldn't. I have these two files:
My first file:
session_start();
$_SESSION['user'] = '1';
My second file:
session_start();
print_r($_SESSION);
echo $_SESSION['user'];
But The second file echoes an empty array. This works fine on my localhost but didn't work on online server. I also have 'register_globals' turned off in php.ini
If you are using cPanel goto cPanel > php.ini QuickConfig >
Check for
session.save_handler = files
session.save_path = /tmp
If you have still facing the problem ask your cPanel guys they will help you
i was also facing the same issue with ipage hosting now it is solved with Radhakrishna Chowdary`s help i did following-
login to your ipage hosting account
go to Additional Tools -> CGI and Scripted Language Support
there choose PHP Scripting
there you will see "Edit your php.ini file for PHP 5.3" click on
edit.
change value of session.save_path `s value to "/tmp"
its done working now :)
iPage requires you to specify the session_save_path() within your script. Like so :
session_save_path("your home directory path"/cgi-bin/tmp);
session_start();
Take a look at this iPage Knowledgebase article for further reference.
Try changing the session variables like $_SESSION['user'] to $_SESSION['userr']
as changing the variable names worked for me for php 5.3 on ipage
Changing 'session.save_path' is not working I tried this a lot but nothing fixed, I contact there support to fix the issue for me, but they said session is disabled in ipage, which is something very bad for cPanel site.
But anyway I recommend another hosting service since iPage doesn't support session which is something main in php development for login and save data.
I recently receive this from IPage customer service:
this mean that the "session.save_path" will never change in 'php.ini', you have to do it in your code as mentioned from there customer service.
Remember to add this line before session start
session_save_path('/home/your/home/directory/path/cgi-bin/tmp');
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.