Php session write path
Сессии являются простым способом хранения информации для отдельных пользователей с уникальным идентификатором сессии. Это может использоваться для сохранения состояния между запросами страниц. Идентификаторы сессий обычно отправляются браузеру через сессионный cookie и используются для получения имеющихся данных сессии. Отсутствие идентификатора сессии или сессионного cookie сообщает PHP о том, что необходимо создать новую сессию и сгенерировать новый идентификатор сессии.
Сессии используют простую технологию. Когда сессия создана, PHP будет либо получать существующую сессию, используя переданный идентификатор (обычно из сессионного cookie) или, если ничего не передавалось, будет создана новая сессия. PHP заполнит суперглобальную переменную $_SESSION сессионной информацией после того, как будет запущена сессия. Когда PHP завершает работу, он автоматически сериализует содержимое суперглобальной переменной $_SESSION и отправит для сохранения, используя сессионный обработчик для записи сессии.
По умолчанию PHP использует внутренний обработчик files для сохранения сессий, который установлен в INI-переменной session.save_handler. Этот обработчик сохраняет данные на сервере в директории, указанной в конфигурационной директиве session.save_path.
Сессии могут запускаться вручную с помощью функции session_start() . Если директива session.auto_start установлена в 1 , сессия автоматически запустится, в начале запроса.
Сессия обычно завершает свою работу, когда PHP заканчивает исполнять скрипт, но может быть завершена и вручную с помощью функции session_write_close() .
Пример #1 Регистрация переменной с помощью $_SESSION .
session_start ();
if (!isset( $_SESSION [ ‘count’ ])) $_SESSION [ ‘count’ ] = 0 ;
> else $_SESSION [ ‘count’ ]++;
>
?>
Пример #2 Отмена объявления переменной с помощью $_SESSION .
НЕ ОЧИЩАЙТЕ $_SESSION целиком, используя unset($_SESSION) , так как это отключит возможность регистрации сессионных переменных через суперглобальную переменную $_SESSION .
Вы не можете использовать ссылки в сессионных переменных, так как не существует реального способа восстановления ссылки к другой переменной.
Замечание:
Сессии, использующие файлы (по умолчанию в PHP), блокируют файл сессии сразу при открытии сессии функцией session_start() или косвенно при указании session.auto_start. После блокировки, ни один другой скрипт не может получить доступ к этому же файлу сессии, пока он не будет закрыт или при завершении скрипта или при вызове функции session_write_close() .
Скорее всего это станет проблемой для сайтов, которые активно используют AJAX и делают несколько одновременных запросов. Простейшим путём решить эту проблему будет вызов функции session_write_close() сразу же как только все требуемые изменения в сессии будут сделаны, предпочтительно ближе к началу работы скрипта. Также можно использовать другой механизм сессии, который поддерживает конкурентный доступ.
User Contributed Notes
session_save_path
session_save_path() returns the path of the current directory used to save session data.
Parameters
Session data path. If specified and not null , the path to which data is saved will be changed. session_save_path() needs to be called before session_start() for that purpose.
Note:
On some operating systems, you may want to specify a path on a filesystem that handles lots of small files efficiently. For example, on Linux, reiserfs may provide better performance than ext2fs.
Return Values
Returns the path of the current directory used for data storage, or false on failure.
Changelog
See Also
User Contributed Notes 5 notes
I made a folder next to the public html folder and placed these lines at the very first point in index.php
Location of session folder:
What I placed in index.php at line 0:
ini_set ( ‘session.save_path’ , realpath ( dirname ( $_SERVER [ ‘DOCUMENT_ROOT’ ]) . ‘/../session’ ));
session_start ();
This is the only solution that worked for me . Hope this helps someone .
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.:
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!
Session on clustered web servers !
We had problem in PHP session handling with 2 web server cluster. Problem was one servers session data was not available in other server.
So I made a simple configuration in both server php.ini file. Changed session.save_path default value to shared folder on both servers (/mnt/session/).
If session.save_handler is set to files, on systems that have maximum path length limitations, when the session data file’s path is too long, php may get you an error like «No such file or directory» and fails to start session, although the session-saving folder really exists on the disk.
1. Keep the session-saving folder’s absolute path not too long
2. If you’re with PHP 7.1+, don’t set session.sid_length to a number too great, such as 255
I once got stuck with this problem on Windows and wasted hours to solve it.
ini_set ( ‘session.save_path’ , realpath ( dirname ( $_SERVER [ ‘DOCUMENT_ROOT’ ]) . ‘/tmp’ ));
ini_set ( ‘session.gc_probability’ , 1 );
session_start ();
?>
(for using above code create a tmp folder/directory in your directory)
- Session Functions
- session_abort
- session_cache_expire
- session_cache_limiter
- session_commit
- session_create_id
- session_decode
- session_destroy
- session_encode
- session_gc
- session_get_cookie_params
- session_id
- session_module_name
- session_name
- session_regenerate_id
- session_register_shutdown
- session_reset
- session_save_path
- session_set_cookie_params
- session_set_save_handler
- session_start
- session_status
- session_unset
- session_write_close
Session Functions
Be aware of the fact that absolute URLs are NOT automatically rewritten to contain the SID.
Of course, it says so in the documentation (‘Passing the Session Id’) and of course it makes perfectly sense to have that restriction, but here’s what happened to me:
I have been using sessions for quite a while without problems. When I used a global configuration file to be included in all my scripts, it contained a line like this:which was used to make sure that all automatically generated links had the right prefix (just like $cfg[‘PmaAbsoluteUri’] works in phpMyAdmin). After introducing that variable, no link would pass the SID anymore, causing every script to return to the login page. It took me hours (!!) to recognize that this wasn’t a bug in my code or some misconfiguration in php.ini and then still some more time to find out what it was. The above restriction had completely slipped from my mind (if it ever was there. )
Skipping the ‘http:’ did the job.
OK, it was my own mistake, of course, but it just shows you how easily one can sabotage his own work for hours. Just don’t do it 😉
Sessions and browser’s tabs
May you have noticed when you open your website in two or more tabs in Firefox, Opera, IE 7.0 or use ‘Control+N’ in IE 6.0 to open a new window, it is using the same cookie or is passing the same session id, so the another tab is just a copy of the previous tab. What you do in one will affect the another and vice-versa. Even if you open Firefox again, it will use the same cookie of the previous session. But that is not what you need mostly of time, specially when you want to copy information from one place to another in your web application. This occurs because the default session name is «PHPSESSID» and all tabs will use it. There is a workaround and it rely only on changing the session’s name.
Put these lines in the top of your main script (the script that call the subscripts) or on top of each script you have:
if( version_compare ( phpversion (), ‘4.3.0’ )>= 0 ) <
if(! ereg ( ‘^SESS9+$’ , $_REQUEST [ ‘SESSION_NAME’ ])) <
$_REQUEST [ ‘SESSION_NAME’ ]= ‘SESS’ . uniqid ( » );
>
output_add_rewrite_var ( ‘SESSION_NAME’ , $_REQUEST [ ‘SESSION_NAME’ ]);
session_name ( $_REQUEST [ ‘SESSION_NAME’ ]);
>
?>How it works:
First we compare if the PHP version is at least 4.3.0 (the function output_add_rewrite_var() is not available before this release).
After we check if the SESSION_NAME element in $_REQUEST array is a valid string in the format «SESSIONxxxxx», where xxxxx is an unique id, generated by the script. If SESSION_NAME is not valid (ie. not set yet), we set a value to it.
uniqid(») will generate an unique id for a new session name. It don’t need to be too strong like uniqid(rand(),TRUE), because all security rely in the session id, not in the session name. We only need here a different id for each session we open. Even getmypid() is enough to be used for this, but I don’t know if this may post a treat to the web server. I don’t think so.
output_add_rewrite_var() will add automatically a pair of ‘SESSION_NAME=SESSxxxxx’ to each link and web form in your website. But to work properly, you will need to add it manually to any header(‘location’) and Javascript code you have, like this:
The last function, session_name() will define the name of the actual session that the script will use.
So, every link, form, header() and Javascript code will forward the SESSION_NAME value to the next script and it will know which is the session it must use. If none is given, it will generate a new one (and so, create a new session to a new tab).
May you are asking why not use a cookie to pass the SESSION_NAME along with the session id instead. Well, the problem with cookie is that all tabs will share the same cookie to do it, and the sessions will mix anyway. Cookies will work partially if you set them in different paths and each cookie will be available in their own directories. But this will not make sessions in each tab completly separated from each other. Passing the session name through URL via GET and POST is the best way, I think.