I'm having trouble with session variable in my setup. I'm storing some data in SESSION variables, but it seems like they're not stored properly, or at least I can't access them. On my local computr running MAMP it works ifne but in prod with php5/nginx, my session variables aren't stored. (I get an undefined index error).
I've read it can be related to the session.save_path and access rights, but I'm still confused. Where is this path defined? In my php.ini file there is this
;session.save_path = "/var/lib/php5"
But it starts with a ';' so I'm guessing it's ignored?
Also, what access should I give to the folder (once I've found it)? How can I know which user php is, and which group it belongs to? Seems like really basic stuff but I'm struggling to grasp it u__u
EDIT:
Apparently it's not a problem of permissions, since there are a lot of session folders in the directory, all created by php... So I really can't figure out why my session variables aren't accessible! :-(
It says undefined index...
Thanks in advance!
Aurélie
It is indeed ignored if it starts with ;. The default value is the temp directory, i.e. /tmp, but just to be sure, I suggest that you look in your phpinfo() and check it there because the file you checked might not be the only configuration your PHP uses.
The sessions path needs to be writable by PHP and it also has to be permitted by the open_basedir directive (if you use open_basedir which is highly recommended).
You use nginx so I'll assume you're using PHP-FPM. To find the PHP-FPM's user, you need to either find the user = ... directive in your php-fpm.conf (usually somewhere under /etc), or you can just find the running process using a tool like ps, htop, etc.
Related
Error during session start; please check your PHP and/or webserver log file and configure your PHP installation properly. Also ensure that cookies are enabled in your browser.
session_start(): open(C:\Windows\TEMP\sess_3ls3qdk77m9mhsf5tm1cdhrm05bi5kb1, O_RDWR) failed: Invalid argument (22)
in my php.ini file: session.save_path = "C:\temp\phpsessions"
Before it was working fine. So sudden it is showing an error.
anyone can assist with this please.
As already stated by other, there is a chance that
Either the C:\temp\phpsessions directory doesn't exist,Or
Else IIS_IUSRS Read/Write Permission is missing in C:\Windows\Temp
there is no problem with your browser.
Double check the permissions on C:\Windows\Temp\ folder. I think IIS_IUSRS needs to have write access in order for files to be saved.
Consider moving the session folder out of C:\Windows\
Where ever you put the sessions, iis will need permissions to edit it.
PHP will not create this directory structure automatically. So make sure this C:\temp\phpsessions directory exist. If not, then you can use the script in the ext/session dir for that purpose or create that directory structure manually.
and then
You can change session save path by writing this line for created directory before session start also note here extra '\' because of escape character.
session_save_path("C:\\temp\\phpsessions");
Most probably it is browser problem. Some mistmatch between browser and session data.
Just in case please do the following:
1. Clear the cache, cookies and temp data of your browser (or use another browser for experimental purposes).
2. Clear the directory where session files are stored on serverside (in your case it seems it is C:\Windows\TEMP or C:\temp\phpsessions. Better clean both of them).
If it does not work please share your php.ini file.
In a module I'm creating I have some sensitive information I need to store securely: A remote database host, username, and password.
It seems that the only storage available is in the Drupal database, which worries me since this means if Drupal is compromised so is this other database. The settings.php file in sites/all/default was my second option, but I'm having trouble writing to it. Various chmod commands in FTP and SSH to 777 and 666 won't open the file to writing. I'm also not sure if the variables I set there are available anywhere else.
Are there any other ways to store this information securely?
You're on the right track using settings.php. You can use the $conf variable in settings.php to set variables that you can access in modules using variable_get.
Hmmm... this seems like something you shouldn't do in general. Write an API that sits at the remote database that you can access.
If however you insist on direct database access. Hard code the host, username and password in a file, put the file outside your document root and include it from there. For example, if your document root (i.e. where Drupal's index.php file is) was /www/htdocs, put a file containing the info at something like /www/secure and include it where you need it. Then if php stops working for some reason, the file isn't in a readable location to the outside world but PHP can include it within the site as necessary.
Sure somebody might see that you were including the file but they wouldn't be able to see the file itself unless they hacked your server (rather than just Drupal) and in that situation, your pretty much screwed anyway.
Using a config file is ideal for this type of information. However doing a chmod 777 or 666 is a really bad idea. The problem is that both of these settings allow the file GLOBALLY read/write. So if you are on a shared host, then its possible for another user on the system to access your file. On install trying using php's chmod() function to do a chmod 500 on the file. (500 should work in most cases, the most important part is that the last number is zero).
when I uploaded the script to the server I got this error
Warning: Unknown: open(/tmp/sess_58f54ee6a828f04116c2ed97664497b2, O_RDWR) failed: Permission denied (13) in Unknown on line 0
Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0
The error appeared when I call session_start(), although I set the permission of /tmp folder to 777.
Change session path where you can write data or contact server administrator about /tmp problem
http://php.net/manual/en/function.session-save-path.php
you will need to change your session.save_path php.ini directive
You can do that using session_save_path
If you have SSH access, here is how to correct the permission and ownership
sudo chown -R NAME_OF_USER /tmp
Replace NAME_OF_USER by the user under which runs php. You can find it by simply putting these lines in a php file:
$processUser = posix_getpwuid(posix_geteuid());
print $processUser['name'];
exit;
Check that you're not running into diskspace issues. If all the permissions are correct (and 777 ought to do it for you), then you might still get this error (for some versions of PHP and Apache) if there isn't enough space to write to the disk.
I had this problem in the following situation:
I filled some session vars with PHP
While the session was still active, I changed from PHP 5.4 to 5.3 on my host.
Reloading the page gave the error, described above.
Reset the PHP version to 5.4 again.
Used session_unset(); and session_destroy(); to clean the current session.
Changed the PHP version back to 5.3.
Now it works again.
Conclusion: For an irrelevant reason I had to change my PHP version, and while switching with sessions alive, the sessions get corrupted.
I realize that this is an old post, however I just ran into this problem, and found an easy solution.
For me, the issue was happening with one of my websites deployed locally. I hadn't tried accessing the websites using other browsers, but it was happening every time I tried to access this site via Chrome. I decided to go into the Chrome developer tools, under the application tab -- and clicking "Clear Storage". Voila -- everything is working like magic again.
Hope this helps someone else!
Additionally, you may want to use ini_set('session.save_path', '/dir/here'); assuming you have access to this function. The other ways suggested are valid.
I've just had exactly the same problem with one of my PHP scripts and I was like what did I break 'cos it worked perfectly the day before and I'm running it from my own local Puppy Linux machine so it's not even a host or anything.
The only thing I'd been doing before that was trying to get Java to work in the web browser, so some how I'd managed to get Java to work but broke PHP - oops!
Anyway I did remember that whilst trying to get Java to work I had deleted the contents of the /tmp folder to wipe anything out that may be causing a problem (it actually turned out with Java I was using the old plugin oij with the new Firefox)
To solve this problem I opened up Rox File Manager, went to the / folder and right clicked on the tmp folder -> Mount Point 'tmp' and clicked properties.
I noticed the permissions were set as Owner - Read, Write, Exec, but Group and World were only set at Read and Exec and not Write. I put a tick in Write for both Group and World and now PHP works fine again.
I don't know at what point the permissions for tmp must have changed but for PHP to use them it must be set to have Write permissions.
Add following line
ini_set('session.save_path', getcwd() . '/tmp');
before
session_start();
if you are using Apache web server, the quick fix is to go to your command line and type:
open /etc/apache2/
then from the window opened, open the file called httpd.conf and search for User or Group change these 2 lines to:
User _www
Group _www
This is because you want your server to have permission to your systems directories, especially you want to change the User or you can leave your Group to either staff or admin.
I had the same problem of permission, but on /var/lib/php/session/.
To fix it, I deleted the file and restarted php-fpm.
rm -rf /var/lib/php/session/sess_p930fh0ejjkeeiaes3l4395q96
sudo service php5.6-fpm restart
Now all works well.
For me the problem seems to be a WHM bug!
I have a bunch of add on domains and all work fine but with a subdomain it brings this error.
Strange thing but if I use the full URL with the main domain it works fine:
main-domain.com/my.subdomain.com
If I use the subdomain directly it brings "Permission denied (13)":
my.subdomain.com
The thing is all addon domains root is:
/home/xx/
But for my subdomain, don't know why, the root is: (I shouldn't have access to that dir)
/
So it´s really trying to reach: /tmp instead of /home/xx/tmp
Which also exists but don't have the right permissions
To clarify this are examples of the whole path:
/home/my-account/public_html
/home/my-account/tmp
/tmp
The workaround I used was:
session_save_path('/home/my-account/tmp');
session_start();
Using PHP 5.6 I had already used session_save_path() to point to a directory within the domain's structure. It worked fine until I upgraded to PHP 7.0, at which time I received the noted error. At PHP.net I found several comments that indicated assigning a direct path didn't always work, so I used their suggestion.
session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));
worked perfectly. Remember to change /../session to the relative location of your actual session directory.
If :
session.gc_probability > 0
session files are created by different user(s) (e.g. root and apache).
session files are all stored in the same place (e.g. /var/lib/php/session)
Then you'll see this error when e.g. the Apache PHP process attempts to run garbage collection on the session files.
Fixes :
Reconfigure PHP so gc_probability is 0, and have a cron job removing the old/stale file(s).
Have each different user save their session files in separate place(s) (session_save_path() etc).
I initially had this issue due to nginx owning the /tmp location and php-fpm was running under 'apache' user and group due to the www.conf. I swapped out the user/group in that file and then it worked ok. You may want to check <?php echo exec('whoami'); ?> to verify.
In my case the problem was SELINUX not allowing this.
A helpful command to get suggestions on how to fix this:
sealert -a /var/log/audit/audit.log
If you want to rule out SELINUX, try disabling it for a moment. If that fixes the issue then that is the problem.
I recently upgraded to PHP 5.3 and since then I get (sporadic) error messages which indicate Apache (or may be the cleaner of the session files) has no permissions to the folder where the sessions are stored.
This happens randomly and can't be reproduced with exact steps, which led me to guess it is the session cleaner.
Any one has any experience with such errors?
The error message (which is fired on the session_start() line) is:
ps_files_cleanup_dir:
opendir(/var/lib/php5) failed:
Permission denied.
ls -ltr on the session directory gives:
drwx-wx-wt 2 root root 4096 2010-05-25 12:39 php5
Inside this directory I do see session files owned by www-data which is my Apache, and the app does work fine.
Which makes me wonder, under which user does the session GC runs?
The fix: In your php.ini set session.gc_probability to 0
The cause
I believe I found the answer here http://somethingemporium.com/2007/06/obscure-error-with-php5-on-debian-ubuntu-session-phpini-garbage
Essentially, the garbage collection is set up to be done by cron jobs on some systems (i.e. Ubuntu/Debian). Some php ini executables like php-cli also try to do garbage collection and that results in the error you got.
This seems to be a typical error on Ubuntu servers (I'm using Lucid LTS). The default permissions of the /var/lib/php5 directory there are
drwx-wx-wt 2 root root 4096 2011-11-04 02:09 php5
so it can be written but not read by the web server, I guess that explains the errors.
As Ubuntu has it's own garbage cleaning via cron (/etc/cron.d/php5), it's probably best to disable php's garbage collection as suggested above by Diwant Vaidya.
session.gc_probability = 0
There's actually a reason the session folder should not be world readable - as the PHP Manual says:
If you leave this set to a world-readable directory, such as /tmp (the
default), other users on the server may be able to hijack sessions by
getting the list of files in that directory.
The solution I currently use (which I am not sure is the correct one) is to give ownership on the session folder to the Apache user (www-data in my case).
This issue has been bugging me for a while. I changed the value as suggested in php.ini and the issue kept occurring. I found the same config value in my index.php and also private/Zend/session.php. So it's worth looking a bit deeper if the issue keeps occurring. I hope this is useful for someone.
I have a default configuration of xampp (LAMP) on a windows system, I have been googleing and reading stackflow for an hour but I can not find where php session data is saved, I would like to locate a session file and look at it.
Some sites say windows usually stores it here C:\windows\tmp\ but I was unable to find it there or anywhere else.
Do you know where sessions are saved
by default?f
Do you know what kind name and file?
extension they might would have?
session_save_path() - they have no extension, they are long string UID named files.
To find the "for sure" location, do the following:
Boot up a cmd prompt
Run php --ini and find the loaded configuration file
Open the config file and search for 'session.save_path'
That's the path your session files should be saved to.
This assumes that session.save_handler is set to 'files', of course, and isn't overridden anywhere in your code.
By default, it's probably "C:\WINDOWS\Temp". The filenames are generally prefixed with sess_, and do not have an extension.
Edit: Other posters are correct in using session_save_path() to find the path as well. That's probably a more foolproof method, in case there's differences between your CLI configuration and your web configuration. I'll hand out some +1's. :D
I find this command the easiest:
php -i | grep session.save_path
CTRL + F (windows Find)... search your XAMPP dir for files modified today (by date)...
Make a php test page. If you haven't done this before simply save the following as a .php file
<?php phpinfo(); ?>
Look for session_save_path under the session section.
If it is set, this should tell you your session path.
You can find where the sessions are stored for the current configuration by calling session_save_path() - this corresponds to the configuration setting session.save_handler as zombat says. The files I think are named by prefixing the session id with 'sess_'
Find Session files in Linux machine
Copy the session cookie from your browser (press F12 and tab to cookies field)
Use grep command with your session cookie value, It will show you the session file name
grep -ir "d79c67d3615b5d208680d51c1c023a6301437715444"
On my xampp session files are directly in "xampp/tmp" location.
Session files starts with prefix "sess_" and then hexadecimal hash.