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.
session_status
session_status() is used to return the current session status.
Parameters
This function has no parameters.
Return Values
- PHP_SESSION_DISABLED if sessions are disabled.
- PHP_SESSION_NONE if sessions are enabled, but none exists.
- PHP_SESSION_ACTIVE if sessions are enabled, and one exists.
See Also
User Contributed Notes 10 notes
Maybe depending on PHP settings, but if return values are not the above, then go for this:
_DISABLED = 0
_NONE = 1
_ACTIVE = 2
Use always session_status(), to check if a session is already started and active.
if(session_status() !== PHP_SESSION_ACTIVE) session_start();
or
if(session_status() === PHP_SESSION_NONE) session_start();
Don’t use
if(!isset($_SESSION)) session_start();
or
if(session_id() === «») session_start();
They will not work properly after a call to session_write_close().
Both functions will continue to report, that the session exists.
And this is right, you can read from $_SESSION, but if you want to write,
you need session_start() again.
As a shorthand you can use
@session_start()
with the @ at the beginning to suppress the
PHP notice «A session had already been started — ignoring session_start()»
As stated in the manual for session_start(), a second call will do no harm,
it will be simply ignored. But you need the @, if you don’t want to get the notice.
Universal function for checking session status.
/**
* @return bool
*/
function is_session_started ()
if ( php_sapi_name () !== ‘cli’ ) if ( version_compare ( phpversion (), ‘5.4.0’ , ‘>=’ ) ) return session_status () === PHP_SESSION_ACTIVE ? TRUE : FALSE ;
> else return session_id () === » ? FALSE : TRUE ;
>
>
return FALSE ;
>
// Example
if ( is_session_started () === FALSE ) session_start ();
?>
Note session_status() is for file based session only.
DB based session status needs to have custom function based on table structure.
The advice of ive_insomnia at live dot com should be taken with great care.
First of all, while his use case for session_status is valid, a simpler way to avoid the warning is:
if (!isset( $_SESSION )) < session_start (); >
?>
The example of session_status uses the raw values of constants (2 in this case) created specifically for the purpose of not having to use magic numbers.
if ( session_status () !== PHP_SESSION_ACTIVE ) < session_start ();>
?>
The same can be done using
The use of this function is lies more towards status management: change the behavior of a script when sessions are disabled altogether, for example.
Just another function to determine whether the session has already started:
function is_session_started () return function_exists ( ‘session_status’ ) ? ( PHP_SESSION_ACTIVE == session_status () ) : ( ! empty ( session_id () ) );
>
This is how the session_status() works:
function session_status () if(! extension_loaded ( ‘session’ )) return 0 ;
>elseif(! file_exists ( session_save_path (). ‘/sess_’ . session_id ()) return 1 ;
>else return 2 ;
>
>
?>
If you started and closed a session then test ( session_id() === » ) to check if a session is active it won’t work, session_id() returns an ID even if the session is closed.
Anybody knows another way before PHP 5.4 to check if a session is really not currently active ?
Here some Good example for your understandingl
if( session_status == PHP_SESSION_NONE ) // if session status is none then start the session
session_start ();
>
?>
old Practice we were using.
if( !( isset( $_SESSION ) ) ) // if the session is no set then start to
new session
session_start ();
>
The purpose of this functionality can aid you specifically in cases where code — prior to your current code — might have opened a session and then closed it.
Specifically, depending on $_SESSION, session_id(), and the SID constant to determine if a session is active will FAIL if a session has previously been opened & closed within the same request cycle.
Please see the original bug report here:
- 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
Функции для работы с сессиями
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 ( ‘^SESS8+$’ , $_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.