CXXXI. Session Handling Functions

简介

Session support in PHP consists of a way to preserve certain data across subsequent accesses. This enables you to build more customized applications and increase the appeal of your web site.

A visitor accessing your web site is assigned an unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.

The session support allows you to register arbitrary numbers of variables to be preserved across requests. When a visitor accesses your site, PHP will check automatically (if session.auto_start is set to 1) or on your request (explicitly through session_start() or implicitly through session_register()) whether a specific session id has been sent with the request. If this is the case, the prior saved environment is recreated.

注意

If you do turn on session.auto_start then you cannot put objects into your sessions since the class definition has to be loaded before starting the session in order to recreate the objects in your session.

All registered variables are serialized after the request finishes. Registered variables which are undefined are marked as being not defined. On subsequent accesses, these are not defined by the session module unless the user defines them later.

警告

Some types of data can not be serialized thus stored in sessions. It includes resource variables or objects with circular references (i.e. objects which passes a reference to itself to another object).

注: Session handling was added in PHP 4.0.

注: Please note when working with sessions that a record of a session is not created until a variable has been registered using the session_register() function or by adding a new key to the $_SESSION superglobal array. This holds true regardless of if a session has been started using the session_start() function.

Sessions and security

External links: Session fixation

The session module cannot guarantee that the information you store in a session is only viewed by the user who created the session. You need to take additional measures to actively protect the integrity of the session, depending on the value associated with it.

Assess the importance of the data carried by your sessions and deploy additional protections -- this usually comes at a price, reduced convenience for the user. For example, if you want to protect users from simple social engineering tactics, you need to enable session.use_only_cookies. In that case, cookies must be enabled unconditionally on the user side, or sessions will not work.

There are several ways to leak an existing session id to third parties. A leaked session id enables the third party to access all resources which are associated with a specific id. First, URLs carrying session ids. If you link to an external site, the URL including the session id might be stored in the external site's referrer logs. Second, a more active attacker might listen to your network traffic. If it is not encrypted, session ids will flow in plain text over the network. The solution here is to implement SSL on your server and make it mandatory for users.

需求

要编译本扩展模块不需要外部库文件。

注: Optionally you can use shared memory allocation (mm), developed by Ralf S. Engelschall, for session storage. You have to download mm and install it. This option is not available for Windows platforms. Note that the session storage module for mm does not guarantee that concurrent accesses to the same session are properly locked. It might be more appropriate to use a shared memory based filesystem (such as tmpfs on Solaris/Linux, or /dev/md on BSD) to store sessions in files, because they are properly locked.

安装

Session support is enabled in PHP by default. If you would not like to build your PHP with session support, you should specify the --disable-session option to configure. To use shared memory allocation (mm) for session storage configure PHP --with-mm[=DIR] .

PHP 的 Windows 版本已经内置该扩展模块的支持。无需加载任何附加扩展库即可使用这些函数。

注: By default, all data related to a particular session will be stored in a file in the directory specified by the session.save_path INI option. A file for each session (regardless of if any data is associated with that session) will be created. This is due to the fact that a session is opened (a file is created) but no data is even written to that file. Note that this behavior is a side-effect of the limitations of working with the file system and it is possible that a custom session handler (such as one which uses a database) does not keep track of sessions which store no data.

运行时配置

这些函数的行为受 php.ini 的影响。

表格 1. Session configuration options

Name	Default	Changeable	Changelog
session.save_path	""	PHP_INI_ALL
session.name	"PHPSESSID"	PHP_INI_ALL
session.save_handler	"files"	PHP_INI_ALL
session.auto_start	"0"	PHP_INI_ALL
session.gc_probability	"1"	PHP_INI_ALL
session.gc_divisor	"100"	PHP_INI_ALL	Available since PHP 4.3.2.
session.gc_maxlifetime	"1440"	PHP_INI_ALL
session.serialize_handler	"php"	PHP_INI_ALL
session.cookie_lifetime	"0"	PHP_INI_ALL
session.cookie_path	"/"	PHP_INI_ALL
session.cookie_domain	""	PHP_INI_ALL
session.cookie_secure	""	PHP_INI_ALL	Available since PHP 4.0.4.
session.use_cookies	"1"	PHP_INI_ALL
session.use_only_cookies	"0"	PHP_INI_ALL	Available since PHP 4.3.0.
session.referer_check	""	PHP_INI_ALL
session.entropy_file	""	PHP_INI_ALL
session.entropy_length	"0"	PHP_INI_ALL
session.cache_limiter	"nocache"	PHP_INI_ALL
session.cache_expire	"180"	PHP_INI_ALL
session.use_trans_sid	"0"	PHP_INI_ALL	PHP_INI_ALL in PHP <= 4.2.3. PHP_INI_PERDIR in PHP < 5. Available since PHP 4.0.3.
session.bug_compat_42	"1"	PHP_INI_ALL	Available since PHP 4.3.0.
session.bug_compat_warn	"1"	PHP_INI_ALL	Available since PHP 4.3.0.
session.hash_function	"0"	PHP_INI_ALL	Available since PHP 5.0.0.
session.hash_bits_per_character	"4"	PHP_INI_ALL	Available since PHP 5.0.0.
url_rewriter.tags	"a=href,area=href,frame=src,form=,fieldset="	PHP_INI_ALL	Available since PHP 4.0.4.

有关 PHP_INI_* 常量进一步的细节与定义参见附录 G。

The session management system supports a number of configuration options which you can place in your php.ini file. We will give a short overview.

session.save_handler string

session.save_handler defines the name of the handler which is used for storing and retrieving data associated with a session. Defaults to files. See also session_set_save_handler().

session.save_path string

session.save_path defines the argument which is passed to the save handler. If you choose the default files handler, this is the path where the files are created. Defaults to /tmp. See also session_save_path().

There is an optional N argument to this directive that determines the number of directory levels your session files will be spread around in. For example, setting to '5;/tmp' may end up creating a session file and location like /tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If. In order to use N you must create all of these directories before use. A small shell script exists in ext/session to do this, it's called mod_files.sh. Also note that if N is used and greater than 0 then automatic garbage collection will not be performed, see a copy of php.ini for further information. Also, if you use N, be sure to surround session.save_path in "quotes" because the separator (;) is also used for comments in php.ini.

警告

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.

注: Prior to PHP 4.3.6, Windows users had to change this variable in order to use PHP's session functions. A valid path must be specified, e.g.: c:/temp.

session.name string

session.name specifies the name of the session which is used as cookie name. It should only contain alphanumeric characters. Defaults to PHPSESSID. See also session_name().

session.auto_start boolean

session.auto_start specifies whether the session module starts a session automatically on request startup. Defaults to 0 (disabled).

session.serialize_handler string

session.serialize_handler defines the name of the handler which is used to serialize/deserialize data. Currently, a PHP internal format (name php) and WDDX is supported (name wddx). WDDX is only available, if PHP is compiled with WDDX support. Defaults to php.

session.gc_probability integer

session.gc_probability in conjunction with session.gc_divisor is used to manage probability that the gc (garbage collection) routine is started. Defaults to 1. See session.gc_divisor for details.

session.gc_divisor integer

session.gc_divisor coupled with session.gc_probability defines the probability that the gc (garbage collection) process is started on every session initialization. The probability is calculated by using gc_probability/gc_divisor, e.g. 1/100 means there is a 1% chance that the GC process starts on each request. session.gc_divisor defaults to 100.

session.gc_maxlifetime integer

session.gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and cleaned up.

注: If you are using the default file-based session handler, your filesystem must keep track of access times (atime). Windows FAT does not so you will have to come up with another way to handle garbage collecting your session if you are stuck with a FAT filesystem or any other fs where atime tracking is not available. Since PHP 4.2.3 it has used mtime (modified date) instead of atime. So, you won't have problems with filesystems where atime tracking is not available.

session.referer_check string

session.referer_check contains the substring you want to check each HTTP Referer for. If the Referer was sent by the client and the substring was not found, the embedded session id will be marked as invalid. Defaults to the empty string.

session.entropy_file string

session.entropy_file gives a path to an external resource (file) which will be used as an additional entropy source in the session id creation process. Examples are /dev/random or /dev/urandom which are available on many Unix systems.

session.entropy_length integer

session.entropy_length specifies the number of bytes which will be read from the file specified above. Defaults to 0 (disabled).

session.use_cookies boolean

session.use_cookies specifies whether the module will use cookies to store the session id on the client side. Defaults to 1 (enabled).

session.use_only_cookies boolean

session.use_only_cookies specifies whether the module will only use cookies to store the session id on the client side. Defaults to 0 (disabled, for backward compatibility). Enabling this setting prevents attacks involved passing session ids in URLs. This setting was added in PHP 4.3.0.

session.cookie_lifetime integer

session.cookie_lifetime specifies the lifetime of the cookie in seconds which is sent to the browser. The value 0 means "until the browser is closed." Defaults to 0. See also session_get_cookie_params() and session_set_cookie_params().

session.cookie_path string

session.cookie_path specifies path to set in session_cookie. Defaults to /. See also session_get_cookie_params() and session_set_cookie_params().

session.cookie_domain string

session.cookie_domain specifies the domain to set in session_cookie. Default is none at all meaning the host name of the server which generated the cookie according to cookies specification. See also session_get_cookie_params() and session_set_cookie_params().

session.cookie_secure boolean

session.cookie_secure specifies whether cookies should only be sent over secure connections. Defaults to off. This setting was added in PHP 4.0.4. See also session_get_cookie_params() and session_set_cookie_params().

session.cache_limiter string

session.cache_limiter specifies cache control method to use for session pages (none/nocache/private/private_no_expire/public). Defaults to nocache. See also session_cache_limiter().

session.cache_expire integer

session.cache_expire specifies time-to-live for cached session pages in minutes, this has no effect for nocache limiter. Defaults to 180. See also session_cache_expire().

session.use_trans_sid boolean

session.use_trans_sid whether transparent sid support is enabled or not. Defaults to 0 (disabled).

注: For PHP 4.1.2 or less, it is enabled by compiling with --enable-trans-sid. From PHP 4.2.0, trans-sid feature is always compiled.
URL based session management has additional security risks compared to cookie based session management. Users may send a URL that contains an active session ID to their friends by email or users may save a URL that contains a session ID to their bookmarks and access your site with the same session ID always, for example.

session.bug_compat_42 boolean

PHP versions 4.2.3 and lower have an undocumented feature/bug that allows you to initialize a session variable in the global scope, albeit register_globals is disabled. PHP 4.3.0 and later will warn you, if this feature is used, and if session.bug_compat_warn is also enabled. This feature/bug can be disabled by disabling this directive.

session.bug_compat_warn boolean

PHP versions 4.2.3 and lower have an undocumented feature/bug that allows you to initialize a session variable in the global scope, albeit register_globals is disabled. PHP 4.3.0 and later will warn you, if this feature is used by enabling both session.bug_compat_42 and session.bug_compat_warn.

session.hash_function integer

session.hash_function allows you to specify the hash algorithm used to generate the session IDs. '0' means MD5 (128 bits) and '1' means SHA-1 (160 bits).

注: This was introduced in PHP 5.

session.hash_bits_per_character integer

session.hash_bits_per_character allows you to define how many bits are stored in each character when converting the binary hash data to something readable. The possible values are '4' (0-9, a-f), '5' (0-9, a-v), and '6' (0-9, a-z, A-Z, "-", ",").

注: This was introduced in PHP 5.

url_rewriter.tags string

url_rewriter.tags specifies which HTML tags are rewritten to include session id if transparent sid support is enabled. Defaults to a=href,area=href,frame=src,input=src,form=fakeentry,fieldset=

注: If you want XHTML conformity, remove the form entry and use the <fieldset> tags around your form fields.

The track_vars and register_globals configuration settings influence how the session variables get stored and restored.

注: As of PHP 4.0.3, track_vars is always turned on.

资源类型

本扩展模块未定义任何资源类型。

预定义常量

以下常量由本扩展模块定义，因此只有在本扩展模块被编译到 PHP 中，或者在运行时被动态加载后才有效。

SID (string): Constant containing either the session name and session ID in the form of "name=ID" or empty string if session ID was set in an appropriate session cookie.

范例

注: As of PHP 4.1.0, $_SESSION is available as a global variable just like $_POST, $_GET, $_REQUEST and so on. Unlike $HTTP_SESSION_VARS, $_SESSION is always global. Therefore, you do not need to use the global keyword for $_SESSION. Please note that this documentation has been changed to use $_SESSION everywhere. You can substitute $HTTP_SESSION_VARS for $_SESSION, if you prefer the former. Also note that you must start your session using session_start() before use of $_SESSION becomes available.
The keys in the $_SESSION associative array are subject to the same limitations as regular variable names in PHP, i.e. they cannot start with a number and must start with a letter or underscore. For more details see the section on variables in this manual.

If register_globals is disabled, only members of the global associative array $_SESSION can be registered as session variables. The restored session variables will only be available in the array $_SESSION.

Use of $_SESSION (or $HTTP_SESSION_VARS with PHP 4.0.6 or less) is recommended for improved security and code readability. With $_SESSION, there is no need to use the session_register(), session_unregister(), session_is_registered() functions. Session variables are accessible like any other variables.
例子 1. Registering a variable with $_SESSION.
<?php session_start(); // Use $HTTP_SESSION_VARS with PHP 4.0.6 or less if (!isset($_SESSION['count'])) { $_SESSION['count'] = 0; } else { $_SESSION['count']++; } ?>

例子 2. Unregistering a variable with $_SESSION and register_globals disabled.
<?php session_start(); // Use $HTTP_SESSION_VARS with PHP 4.0.6 or less unset($_SESSION['count']); ?>

注意

Do NOT unset the whole $_SESSION with unset($_SESSION) as this will disable the registering of session variables through the $_SESSION superglobal.

警告

You can't use references in session variables as there is no feasible way to restore a reference to another variable.

例子 3. Unregistering a variable with register_globals enabled, after registering it using $_SESSION.
<?php session_start(); // With PHP 4.3 and later, you can also simply use the prior example. session_unregister('count'); ?>

If register_globals is enabled, then each global variable can be registered as session variable. Upon a restart of a session, these variables will be restored to corresponding global variables. Since PHP must know which global variables are registered as session variables, users need to register variables with session_register() function. You can avoid this by simply setting entries in $_SESSION.

注意

Before PHP 4.3, if you are using $_SESSION and you have disabled register_globals, don't use session_register(), session_is_registered() or session_unregister().

If you enable register_globals, session_unregister() should be used since session variables are registered as global variables when session data is deserialized. Disabling register_globals is recommended for both security and performance reasons.

例子 4. Registering a variable with register_globals enabled


<?php
if (! isset($_SESSION['count'])) {
    $_SESSION['count'] = 1;
} else {
    $_SESSION['count']++;
}
?>

If register_globals is enabled, then the global variables and the $_SESSION entries will automatically reference the same values which were registered in the prior session instance.

There is a defect in PHP 4.2.3 and earlier. If you register a new session variable by using session_register(), the entry in the global scope and the $_SESSION entry will not reference the same value until the next session_start(). I.e. a modification to the newly registered global variable will not be reflected by the $_SESSION entry. This has been corrected in PHP 4.3.

Passing the Session ID

There are two methods to propagate a session id:

Cookies
URL parameter

The session module supports both methods. Cookies are optimal, but because they are not always available, we also provide an alternative way. The second method embeds the session id directly into URLs.

PHP is capable of transforming links transparently. Unless you are using PHP 4.2 or later, you need to enable it manually when building PHP. Under Unix, pass --enable-trans-sid to configure. If this build option and the run-time option session.use_trans_sid are enabled, relative URIs will be changed to contain the session id automatically.

注: The arg_separator.output php.ini directive allows to customize the argument seperator. For full XHTML conformance, specify & there.

Alternatively, you can use the constant SID which is always defined. If the client did not send an appropriate session cookie, it has the form session_name=session_id. Otherwise, it expands to an empty string. Thus, you can embed it unconditionally into URLs.

The following example demonstrates how to register a variable, and how to link correctly to another page using SID.
例子 5. Counting the number of hits of a single user
<?php if (!session_is_registered('count')) { session_register('count'); $count = 1; } else { $count++; } ?> <p> Hello visitor, you have seen this page <?php echo $count; ?> times. </p> <p> To continue, <a href="nextpage.php?<?php echo strip_tags(SID); ?>">click here</a>. </p>

The strip_tags() is used when printing the SID in order to prevent XSS related attacks.

Printing the SID, like shown above, is not necessary if --enable-trans-sid was used to compile PHP.

注: Non-relative URLs are assumed to point to external sites and hence don't append the SID, as it would be a security risk to leak the SID to a different server.

Custom Session Handlers

To implement database storage, or any other storage method, you will need to use session_set_save_handler() to create a set of user-level storage functions.

目录
session_cache_expire -- Return current cache expire
session_cache_limiter -- Get and/or set the current cache limiter
session_commit -- 别名 session_write_close()
session_decode -- Decodes session data from a string
session_destroy -- Destroys all data registered to a session
session_encode -- 将当前会话数据编码为一个字符串
session_get_cookie_params -- Get the session cookie parameters
session_id -- Get and/or set the current session id
session_is_registered -- Find out whether a global variable is registered in a session
session_module_name -- Get and/or set the current session module
session_name -- Get and/or set the current session name
session_regenerate_id -- Update the current session id with a newly generated one
session_register -- Register one or more global variables with the current session
session_save_path -- Get and/or set the current session save path
session_set_cookie_params -- Set the session cookie parameters
session_set_save_handler -- Sets user-level session storage functions
session_start -- Initialize session data
session_unregister -- Unregister a global variable from the current session
session_unset -- Free all session variables
session_write_close -- Write session data and end session

add a note User Contributed Notes

cbm at cbmaspire dot com
04-Nov-2006 01:45


I discovered a new quirk with the use of session, php includes, and IE7. I have spent a lot of time tracking down a bug where my login session would start and work on the first page but then terminate requiring login again on any page clicked from an included menu. What I discovered is that the included menu links would actually create a whole new session with a new session id and my login security script was looking for the first session id. I found a way to fix this issue by doing a simple url inclusion of the original session id.



Example:



page1.php:

<?php



include_once("memberonly.php");



?>

<html>

<head>

</head>

<body>

<!-- html top part of page -->

<? include_once("menu.php"); ?>

<!-- more html -->

</body>

</html>



menu.php:



<a href="http://www.whatever.com/page2.php?sessid=<? session_id() ?>">page2</a>



By passing the session id, session keeps the correct id on the clicked link. Apparently because this is an include on page 1, it acts as a whole new http request when one of the links on the included page is clicked. This same issue has also occurred in the firefox browser when I tested the site before the fix. Hopefully, for everyone using session for their login scripts and using page includes in the tabbed browsers, this will fix your issue.

klenwell at gmail dot com
06-Oct-2006 08:39


In response to marou at marou dot com responding to fondman at hotmail dot com regarding local variables overwriting SESSION variables:



I was encountering this same problem.  On my local PHP 5 server, no problem.  Remote host's server running PHP 4: major headaches.



Initially, I concluded it was some kind of bug in PHP 4 and older.  However, according to the devs, this is not a bug (see http://bugs.php.net/bug.php?id=36366).  Apparently, this is intended behavior when register_globals is set to ON.  



But, as noted elsewhere in the docs, register_globals cannot be turned off at runtime using ini_set().  However, you can use a local .htaccess or php.ini to override the setting.  This site helped me solve the problem:



http://www.nyphp.org/phundamentals/ini.php



Full details of my experience with this issue can be found here:



http://tinyurl.com/o6p7y

wings at 25th dot com
05-Oct-2006 09:59


Jestin's Session class is a nice alternative, but I had trouble with it.  The results of the filesize() function are cached.  I ended up having to put a call to clearstatcache() at the head of Session::_getdata();  Otherwise, your session data gets truncated.

jon at jonroig dot -----com
27-Sep-2006 07:30


This code is to solve a problem that's probably becoming more common as we move into the AJAX world -- how the &*^*&^ to access session data if you're transferring data back 'n' forth from a server and you don't have cookies to help you out.





The function accepts the session ID then grabs the session data straight from the directory, parses it, and returns it as an array.





<?


function grabSessionData($sessionInput)


  {


  $sessionThing = "/tmp/sess_".$sessionInput;


  $textContentsArray = file($sessionThing);


  $serializedData = '';





  foreach ($textContentsArray as $line => $textLine)


    {


    $serializedData = $serializedData.$textLine;


    }


  $sessionArray = explode(";",$serializedData);


  $sessionDataArray = array();


  foreach ($sessionArray as $line => $dataLine)


    {


    $dataArray2 = explode('|',$dataLine);


    $dataArray3 = explode(':',$dataLine);


    $sessionDataArray[$dataArray2[0]] = 


      str_replace('"','',$dataArray3[count($dataArray3)-1]);


    }


  return $sessionDataArray;


  }





// example


$sessionInfoArray = grabSessionData('f58c92b76c1dd553c56dd428ea7a1bfc');


?>

steffen at steffen-ille dot de
13-Sep-2006 08:02


old problem was:

internet explorer has security settings which reject your php session cookie within different framesets (third party cookies). one approach to handle this was to pass the session id to the other frames in the url. the www says, this is a little bit unsafe...



another trick to handle this is, to trick the explorer with the php header funktion. as described in the microsoft knowledgebase

article http://support.microsoft.com/kb/323752/EN-US/



you simply add a header at the top of your scripts _bevore_ the session_start() is called:



header('P3P: CP="CAO PSA OUR"');



and now test it and enjoy...

13-Sep-2006 02:28


Here is a replacement I wrote for Session Handeling.



Before use, you must replace "[--PATH-TO-SESSION-FOLDER--]" with the path to where sessions should be stored.  Make sure to set the proper permissions for that folder :)



--------------------------------------------------------------------



<?

 class Session

 {

  function _makeid()

  {

   $time    = time();

   $ip      = $_SERVER["REMOTE_ADDR"];

   $agent   = $_SERVER["HTTP_USER_AGENT"];

   $md5 = md5($time.$ip.$agent);

   setcookie("SClass", $md5);

   return($md5);

  }



  function getid()

  {

   $md5 = $_COOKIE['SClass'];

   return($md5);

  }



  function start()

  {

   $id = $this->getid();

   if (!$id) { $id = $this->_makeid(); }

  }



  function _getfile()

  {

   $file = $this->getid();

   $file .= ".ssn";

   $file = "[--PATH-TO-SESSION-FOLDER--]".$file;

   return($file);

  }



  function _setdata($data)

  {

   $file = $this->_getfile();

   $fs   = @fopen($file, w);

   if ($fs) { fwrite($fs, $data); fclose($fs);}

   if (!$fs) { return(FALSE); }

  }



  function _getdata()

  {

   $file = $this->_getfile();

   $fs   = @fopen($file, 'r');

   if ($fs) { $data = fread($fs, filesize($file)); fclose($fs); return $data; }

   if (!$fs) { return(FALSE); }

  }



  function set($key, $value)

  {

   $data          = $this->_getdata();

   $data          = base64_decode($data);

   $array         = unserialize($data);

   $array["$key"] = $value;

   $newdata       = serialize($array);

   $newdata       = base64_encode($newdata);

   $this->_setdata($newdata);

  }



  function get($key)

  {

   $data = $this->_getdata();

   $data = base64_decode($data);

   $array = unserialize($data);

   return($array[$key]);

  }



 }

?>



--------------------------------------------------------------------

Useage:



 $Session = new Session();

 $Session->start();

 $Session->set($key, $value);

 $sessionvalue = $Session->get($key);



--------------------------------------------------------------------



- Jestin S Larson

nhap24
09-Sep-2006 08:03


I spent about 8 hours debugging a problem with sessions and redirecting, and I finally found the problem, which after looking back, should have been the first thing I tried.



I use sessions to prevent hotlinking, so if someone hotlinks my file, I will redirect them to a different page by re-writing the header information.  When I redirected, I sent path information in the GET data about the file they were trying to access.  Long story short, when I redirected with a forward-slash "/" AFTER the .php, the page would create a different session ID than the rest of my domain was using.  This happened despite the fact that the cookie path was set to "/" (which should have captured any path on my domain).  



The issue was even harder to figure out, because the page with the wrong session ID was NOT creating a second cookie.  The only cookie was the one with the proper ID, but the broken page did not use this cookie (where then, did it get this ID from?).



To fix the problem, I simply removed the forward-slash from the GET data (base64_encoding works nicely).



I imagine this is an issue with my browser parsing the url, but I tried both Opera and Firefox (IE doesn't load anymore :/) and both browsers showed the same problem.



I looked into hidden header data, failure to write the cookie, trans_ses_id (even though it was set to false), HTTP_HOST, everything, but in the end it was just a stupid forward-slash that had done me in.

greenthumb at 4point-webdesign dot de
02-Sep-2006 02:56


Similar to the use of captcha images you can easely track and advise user who don't accept cookies, especially no session cookies without redirecting them.



so here's the deal:



if the main script (which outputs the html) doesn't have a value in it's session which says that a session is running successfully a different value is saved in the session and an image is included in the html which checks wether the session-check value is set or not. 



If it's set the image-script sets a confirming value which will verify the session to be running correctly and output a transparent 1*1px gif.



If the value is not set the image outputs an advising image which tells to allow cookies.



You can also wrap the image with a link who refers the user  to a page addressing the cookie issue. If the 1px trans is generated the user will hardly find the link, but if the error-image is generated he will surely be able to click it.



pros: 

- works

- no rerouting, you can see the result on the first page opened by the user

- no javascript



cons: 

- bad accessebility (if you give the image an alt-text any blind user will read it at least on the first call, but you cold also write this into the alt text... so maybe there are no cons)



i hope this'll help

in dot tray at NOSPAM dot tiscali dot co dot uk
24-Aug-2006 09:19


Some users turn off cookies on their browser. It would be nice to advise such users that they need to switch on cookies to use your web site, especially if you do not allow URL session IDs.



The first request to your site will not contain cookie data from the user. Some developers do a little trick on the server at this point to redirect the user to the same or different page and in so doing endeavour to deliver a cookie so that it can then be determined if this was successful on the second request. It has the advantage of letting the no-cookie user know at the on-set if there is a problem. Of course this adds an overhead of time and server resources. It also might impare your site's position with popular search engines.



So, since many sites will work to a point without sessions working (i.e. scatterings of static links and basic searches), I allow the user to load the first page and then perform the cookie check upon the user's subsequent request. If the cookie canot be found I place advice text accordingly  



simple (unchecked) solution...



function cookie_check() {

if (!isset($_COOKIE['PHPSESSID'])) {

return false;

} else {

return true;

}



if (!cookie_check()) {

echo "This site uses cookies, dah dah dah...";

}



I have looked fairly extensively for information on this issue but there isn't a great deal about. So, if anyone out there has more experience of this...

Bruno Negrao G Zica
24-Aug-2006 09:13


#! /bin/sh

# NAME

#       mod_files.sh  - Update of the php-source/ext/session/mod_files.sh

#

# SYNOPSIS

#       mod_files.sh basedir depth [numberofsubdirs]

#

# DESCRIPTION

#       this script creates the directories tree used by php to store the session files

#       (see php.ini - 'session.save_path' option)

#

#       Example: if you want php to store the session files in a directory tree

#       of 3 levels of depth containing 32 directories in each directory,

#       first, put the setting bellow in the php.ini file:

#

#       session.save_path = "3;/tmp/session"

#

#       Now create the basedir directory: 'mkdir /tmp/session'

#

#       Then, call this scrip with the following arguments:

#

#       ./mod_files.sh ./mod_files.sh /tmp/session 3 32



if test "$2" = ""; then

        echo "usage: $0 basedir depth [numberofsubdirs]"

        echo "numberofsubdirs: if unset, defaults to 16. if 32, 32 subdirs, if 64, 64 subdirs."

        exit 1

fi



if test "$2" = "0"; then

        exit 0

fi



hash_chars="0 1 2 3 4 5 6 7 8 9 a b c d e f"

if test "$3" -a "$3" -eq "32"; then

  hash_chars="$hash_chars g h i j k l m n o p q r s t u v"

  if test "$3" -eq "64"; then

    hash_chars="$hash_chars w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z - ,"

  fi

fi



for i in $hash_chars; do

        newpath="$1/$i"

        mkdir $newpath || exit 1

        sh $0 $newpath `expr $2 - 1` $3

done

entropicchild
24-Aug-2006 12:09


I just went looking through the /tmp dir on a shared hosting server, and noticed all the php sessions stored there (bad idea for shared hosting). I noticed that some of these people/scripts are storing plain-text passwords in their sessions (another very bad idea). Here's a hint people: do not store ANYTHING that may present a security risk in the session data! This includes, passwords, creditcard information, etc. 



It is best, under ALL circumstances that a dir other than /tmp be used for session data. Btw, whomever it was that said it was no more secure to use a diff dir was wrong. The /tmp dir is a globally readable/writable dir.



If you are using shared hosting, then you better be sure your session data is being saved within your home dir and NOT web-accessible. If you are a shared hosting sysadmin, you should be doing this for your users automatically... as well as any other tmp files (file uploads, etc...).

http://mike.eire.ca/
10-Aug-2006 06:08


It should be noted that PHP makes the decision about whether SID is empty based on the HTTP request.  Specifically, if there is no cookie sent with the GET or POST request, SID is populated when the session is initiated.



What does this mean?  If you want your site to support clients who have cookies disabled, your links will have PHPSESSID appended to them on the page where the session is created.



It seems like the only way around this is a double redirect...

Eric dot Deplagne at nerim dot net
01-Aug-2006 06:34


One more note on session duration, and especially long sessions. I hope I've now understood the problem, and this may be useful.



The duration of a session is indeed controlled by many things (too many for my taste).



The first thing is session.cache_expire, which should be *the* thing, you can set it with ini_set(), or with session_cache_expire(). The value is in minutes, and defaults to 180, which is 3 hours and should be enough.

 

  <?php //ini_set("session.cache_expire","180"); // default is 180, which is 3 hours... ?>



But that does not work !



Second thing to take into account, session.gc_maxlifetime. Indeed, if the garbage collector kills your session data, you're lost. So we set it with ini_set. The value is in seconds, and defaults to 1440, which is only 24 minutes and might be a little short.



  <?php ini_set("session.gc_maxlifetime","3600"); // default is 1440, which is only 24 minutes ?>



Here I should have a 1 hour session. But in fact, I don't !



Third thing to take into account, session.save_path. If other people mess up with it, like if it's "/tmp" as it is by default, and their gc has not the same idea as yours, you're lost. So we set it with ini_set or session_save_path.



  <?php session_save_path("/my/own/path/without/url/sessions"); ?>



Here we are. As you can read in the example it should be a path you control (and your web server can write), with no access via URL.



Of course, all these parameters must be set before calling session_start().



In fact, two other variables (at least) play a role in session duration, and will explain that the session might last more than expected. The gc erasing your data is a probabilistic thing. Each time a session is opened, the probability the gc is started is session.gc_probability/session.gc_divisor. session.gc_probability defaults to 1 and session.gc_divisor defaults to 100, which makes a 1% probability.



This is to have sessions long enough. I'm unsure about having sessions lasting exactly the time we want them to.

rehevkor5 at fastmail dot fm
26-May-2006 02:34


If you have a value specified for session.referer_check you may run into difficulty when someone accesses your site and attempts to log in with a mis-capitalized URL.  The logon will fail because any calls to session_start() will result in the existing session being trashed and a new one being created.  This becomes a bigger problem when the logon is followed by a header("Location: ...") redirect, because the session_start() at the top of the page will fail.



Because session_start() always returns true, it's not obvious how to detect when the referer check fails.  To detect it, I have come up with a method which compares the intended session id with the session id after session_start() is run.  If they are different, the user is redirected to the proper location.  This example uses a technique to avoid session id fixation, as well.



ini_set('session.referer_check', 'www.yourdomain.edu/ltr/');

ini_set('session.use_only_cookies', 1);

session_name('yourapp'.str_replace('.', '', $_SERVER['REMOTE_ADDR']));

session_start();

if($_GET['badreferer'])

    echo 'You tried accessing the site with a bad URL. Try logging on again.';

if(isUserAuthed($name, $pass))

{

    $old_sessid = session_id(); //save current session id so we can delete it later

    if( !session_regenerate_id() ) //get a new session id (must do this before destroying the old session)

        die("Couldn't regenerate your session id.");

                

    $new_sessid = session_id(); //save new session id so we can get back to it

                

    session_id($old_sessid);

    unset($old_sessid);

    session_destroy(); //destroy the session they got before they logged in

                

    session_id($new_sessid);

    session_start(); //start the new session

                

    $_SESSION = array(); //not really necessary any more, but still a good idea

                

    if(session_id() != $new_sessid)

    {

        /*If this is true, then the session_start() failed to work properly. If session_start() failed to work properly, the most likely cause is that the referer url is different from that set in fuxebox.ini on session.referer_check. The most common cause of this is URL capitalization problems. Therefore, we relocate them to the proper URL, and set a flag to display an error because we can't use pushError() if the session isn't valid. */

                    

        $good_url = ini_get('session.referer_check');

        header('Location: http://'.$good_url.'?badreferer=1');

        exit;

    } else {

        unset($new_sessid);

        //Set session variables here

        $_SESSION['isloggedin'] = 1;

        

        echo 'You have been logged in.';

    }



}

rajasekhar_s7 at yahoo dot co dot in
19-May-2006 07:07


POST the variable can give the page Expire Warnig when you press the BACK button.

                Solution: Put this code on the page top.

            <?    session.cashe.limiter(private, must-revalidate)  ?>

php AT coryforsyth [removeme] d0t com
09-May-2006 10:14


I just finished a marathon debugging session with sessions, and I wanted to share what I learned with the rest of the PHP community because this has been a problem I've battled on several projects before finally solving it today.



I am using sessions to register a user's ID, and every so often, for no apparent reason, the session would seem to expire and my logged-in user would get kicked out.



This is the code I am using to validate a user:

<?php

session_start();



$auth = false;



if (isset($_SESSION['user_id'])) {

   $user = new User($_SESSION['user_id']);

   $auth = true;

else {

   $login = $_REQUEST['login'];

   $password = $_REQUEST['password'];

   $login = clean($login);

   $password = clean($password);

   // clean() is my own function to escape quotes and so on

   $user = checkLogin($login,$password);

   if (!is_null($user)) {

        $auth = true;

   }

}



if (!$auth) {

   die("you must log in.");

}



// etc etc ... //

?>



I was scratching my head as to why, on about 10% of the times I sent a user to a new page (a PHP page that didn't have any of the sessions stuff--no session_start() and no mention of any session variables), when they came back the session variables were all empty.



I came upon a clue when I used ini_set to change the session.save_path location.  My idea was that maybe the session files in /tmp were being deleted by other users on the system or something.  So I added this line before session_start():

<?php

ini_set('session.save_path',"/path/to/unique/dir/");

?>

I knew no one else was saving their sessions there, so I started logging in to my page and at the same time checking for the creation of new sess_* files.  I noticed that sometimes, especially when I had problems, a second session file (that was empty) would appear.



What I realized was that the URL was changing from www.coryforsyth.com to coryforsyth.com.  When the presence of the WWW changed, PHP thought it was a different session and created an empty one that caused my script to log me out.  If I went to the location bar of my browser and added/removed the WWW (to the way it had been before), all was well and I was still logged in.



An incredibly thorny problem. I hope this post helps someone else fix it, or even better prevent it.  I changed my hosting preferences to automatically add a WWW to my domain if it wasn't typed that way.



thanks,

Cory Forsyth

brady at volchok dot com
18-Apr-2006 03:15


Session locking (concurrency) notes:



As mentioned several times throughout this section on Sessions, the default PHP session model locks a session until the page has finished loading. So if you have two or three frames that load, and each one uses sessions, they will load one at a time. This is so that only one PHP execution context has write access to the session at any one time.



Some people work around this by calling session_write_close() as soon as they've finished writing any data to the $_SESSION - they can continue to read data even after they've called it. The disadvantage to session_write_close() is that your code still will lock on that first call to session_start() on any session'ed page, and that you have to sprinkle session_write_close() everywhere you use sessions, as soon as you can. This is still a very good method, but if your Session access follows some particular patterns, you may have another way which requires less modification of your code.



The idea is that if your session code <b>mostly</b> reads from sessions, and rarely writes to them, then you can allow concurrent access. To prevent completely corrupted session data, we will lock the session's backing store (tmp files usually) while we write to them. This means the session is only locked for the brief instant that we are writing to the backing store. However, this means that if you have two pages loading simultaneously, and both modify the session, the <i>Last One Wins</i>. Whichever one loads first will get its data overwritten by the one that loads second. If this is okay with you, you may continue - otherwise, use the session_write_close method, above.



If you have complicated bits of code that depend on some state in the session, and some state in a database or text file, or something else - again, you may not want to use this method. When you have two simultaneous pages running, you might find that one page runs halfway through, modifying your text file, then the second one runs all the way through, further modifying your text file, then the first one finishes - and your data might be mangled, or completely lost.



So if you're prepared to debug potentially very, very nasty race conditions, and your access patterns for your sessions is read-mostly and write-rarely (and not write-dearly), then you can try the following system. 



Copy the example from session_set_save_handler() into your include file, above where you start your sessions. Modify the session write() method:



<?

function write($id, $sess_data)

{

  global $sess_save_path, $sess_session_name;



  $sess_file = "$sess_save_path/sess_$id";

  if ($fp = @fopen($sess_file, "w")) {

   flock($fp,LOCK_EX);

   $results=fwrite($fp, $sess_data);

   flock($fp,LOCK_UN);

   return($results);

  } else {

   return(false);

  }



}

?>



You will probably also want to add a GC (Garbage Collection) method for the sessions, as well.



And of course, take this advice with a grain of salt - We currently have it running on our testing server, and it seems to work OK there, but people have reported terrible problems with the Shared Memory session handler, and this method may be as unsafe as that.



You can also consider implementing your own locks for scary concurrency-sensitive bits of your code.

marcosdsanchez {a t} gmail [_dot_] com
08-Apr-2006 10:52


********************WARNING***********************



There's a bug in Internet explorer in which sessions do not work if the name of the server is not a valid name. For example...if your server is called web_server (_ isn't a valid character), if you call a page which uses sessions like http://web_server/example.php your sessions won't work but sessions will work if you call the script like this



[IP NUMBER]/example.php



Took me a lot of time to find out why my PHP sessions worked perfectly in Firefox and Opera but they didn't work in internet explorer



***************************************************

Cosmo
01-Apr-2006 08:47


Fairly new to PHP, I've been looking to alter session timeouts on a shared host where I don't have direct access to configure php.ini.  There doesn't appear to be any easy way to find out how to do this in this manual (nor from a quick web search).



The code below seems to work OK to set session timeout.     a timeout of 30 secs is used for convenient testing.  gc settings must come before session_start().



The garbage collection is made 100% by setting probability and divisor to the same value - if I have correctly understood what these functions do.

  

(on the first pass of the file, there is no session file - that's established only when the script ends for the first time.  Keep reloading to test).



Comments welcome.



<?php

  ini_set('session.gc_maxlifetime',30);

  ini_set('session.gc_probability',1);

  ini_set('session.gc_divisor',1);

    session_start();

    

// check to see what's happening

$filepath = ini_get('session.save_path').'/sess_'.session_id();

    

if(file_exists($filepath)) 

{

    $filetime = filemtime ($filepath);

    $timediff = mktime() - $filetime;

    echo 'session established '.$timediff.' seconds ago<br><br>';

}

?>

Josh
09-Mar-2006 02:35


I had users of my site occsaionally complaining that they were being logged out after short times of inactivity (usually when they were creating content to send to the site). I had a high cookie timout so I couldn't understand why this was happening, and I never managed to replicate the behaviour myself. 



I've just come accross the "gc_maxlifetime" property. This seems to be the culprit; it's set to only 24 minutes! The worst part is that it combines with the "gc_probability" property to produce unpredictable results. I'm mysified as to why the time limit is so low by default, but hopefully increasing it will fix up my errors.

crown2gain at yahoo dot com
02-Mar-2006 02:19


I just spent a lot of time trying to figure out why my session variables were not available after I seemed to have set them(could echo after setting).  I use the same script for several different functions, so the user may reload the page for other purposes.  Someone else posted the use of session_write_close();  before a Location redirect.  This also worked in put this after I set the session variables the variables are available when the page reloads for another function.



$_SESSION['guid'] = $guid;

$_SESSION['userdata'] = $response;

session_write_close();

a l bell at hutchison dot com dot au
01-Mar-2006 07:17


Please Note;



Internet explorer users beware.



When using session_start() to begin a session this session will remain open until the page has finished loading or it is explicitly terminated.



You can lose the session however if the the page contains a reference to <img src=""> with name and id references (which may be used if the image is referencing a dynamic image, called by javascript)  This seems to casue IE6 to refresh the page session id and hence loose the session.



This took hours for me to diagnose when users were getting unexpectedly logged out of my site due to this "" in the img src.

kintar at infinities-within dot net
01-Mar-2006 01:10


Important note that it just took me the better part of two hours to figure out:  Even if you're using session_write_close(), calling exit after a redirect will eat your session variables.  I had the following:



Source of register.php:

<?PHP



// Some files included here



// Process our posted form data

$result = processPost();



if ($result)

{

  redirect('success.php');

}

else

{

  redirect('failure.php');

}



exit;

?>



processPost() was setting a couple of session variables, including an error message, but neither results page was seeing those variables.  I removed the exit call from the register page, and all works fine.



/bonks self

phpkloss at wholewheatradio dot org
22-Feb-2006 04:57


If you're having trouble with unset($_SESSION[$something]) working, here's what I discovered (Win2K/PHP 5.x.x).  Assume you want to step through $_SESSION and delete (i.e. unset) certain elements.  So,



foreach ($_SESSION as $key=>$value) {

   if (stristr($key,'something_to_delete')) {

     echo "Will unset $key that has value of $value";

      unset($_SESSION[$key]);

}



What I found was that although the $_SESSION elements were deleted in memory, the actual session file was not being written out with the changes (even after using session_write_close).  What fixed it for me was to COPY $_SESSION INTO A DUMMY ARRAY, THEN STEP THROUGH THAT DUMMY ARRAY TO FIGURE OUT WHICH ELEMENTS OF THE REAL $_SESSION TO DELETE.  I.e.



foreach($_SESSION as $key=>$value) {

  $dummy[$key]=$value;  // copy to a dummy array

}



foreach ($dummy as $key=>$value) {

   if (stristr($key,'something_to_delete')) {

     echo "Will unset $key that has value of $value";

      unset($_SESSION[$key]);

}



It appears that as you're stepping through the actual $_SESSION array in a foreach, if you unset elements of it, those changes won't be recorded to the session disk file.



'Course then again, my coffee is running low so I could be wrong.  But hopefully it's something others can try who might be having a similar problem.

21-Feb-2006 02:21


In response to "djohnson at jsatech dot com", posted 09-Dec-2005 09:00



"Be warned, when working with tab-based browsers like Opera and Firefox, sessions are preserved across tabs....IE deals with sessions just fine.  There is probably some way to adjust the settings in Firefox or Opera, but that is not the default, and will affect most users."



In fact, the way sessions are managed among different browsers is not all that different among MSIE and Opera and Firefox.  You will find that MSIE sessions can be maintained across browser windows, just like in FF or Opera.  However the difference that djohnson noted is because of the way MSIE windows are created vs FF and Opera.



If you choose, in MSIE, "File->New Window", you will find that PHP sessions are preserved from browser window to browser window.



If, OTOH, you start a new window of MSIE using the start menu or desktop icon, a new instance of MSIE, with a new process ID, is started.  *This* instance does not have anything to do with any other previously existing MSIE instances, and, thus, PHP sessions started in this new MSIE process are distinct from PHP sessions in existing MSIE instances.



See the difference?



Whereas FF and Opera apparently always start a new window into an existing FF or Opera process.  Thus PHP sessions are always maintained across browser instances with FF and Opera.

hans at nieser dot net
14-Feb-2006 11:15


FreeBSD users, instead of modifying the PHP5 port Makefile, you can either install the session extension using the www/php5-session port, or you can install several extensions at once (you can pick them from a menu) using the lang/php5-extensions port. Same goes for PHP4

just_somedood at yahoo dot com
02-Feb-2006 01:31


If you're running FreeBSD, and installed php5 (have not checked 4) from the ports, and are getting errors saying the session functions are undefined, try running phpinfo().  You'll probably see that the '--disable-all' configure command was used.  To fix, edit the /usr/ports/lang/php5/Makefile, and remove the '--disable-all' line.  In that directory, run a 'make deinstall', if you installed already.  Next, run 'make install' while still in that same directory.  It should work fine after that.

warkangaroo
27-Jan-2006 12:33


After hitting my head on the desk a few times trying to debug this construct,



$_SESSION['result']['number'] = $blah;



returning the warning,



"Warning: Cannot use a scalar value as an array"



and not saving my value, I found out that apparently $_SESSION['result'] is a reserved variable... I changed it to $_SESSION['bresult'] and it works fine.



Just trying to save someone a headache...

james dot ellis at gmail dot com
26-Jan-2006 04:23


If you are wondering why your garbage cleanup method is not being called, read on.



The manual notes for garbage cleanup state that the session.gc_divisor defaults to 100:



[code]

//http://php.net/manual/en/ref.session.php

session.gc_probability  ... Defaults to 1.

session.gc_divisor  .... session.gc_divisor defaults to 100. 

[/code]



This would provide a gc probability of 1 in 100 ie. your garbage cleanup is going to be called 1% of the time.



Conversely, my PHP 5.1.1 install, compiled from source, contains this in the php.ini-recommended file (and my php.ini file):

[code]

; Define the probability that the 'garbage collection' process is started

; on every session initialization.

; The probability is calculated by using gc_probability/gc_divisor,

; e.g. 1/100 means there is a 1% chance that the GC process starts

; on each request.



session.gc_probability = 1

session.gc_divisor     = 1000

[/code]



A 0.1% probability by default. Based on the information provided, I set my gc_probability to 100,  thus providing a 1% probability stale sessions would be culled.



Moral:your local php.ini may differ from what the manual provides.

jerry dot walsh at gmail dot com
24-Jan-2006 10:56


If you're using sharedance to distributed php sessions across a group of machines beware of the following:



On a freebsd 6.x system I have observed a huge performance hit caused by dns/host file lookups.



To ensure maximum performance using sharedance you should set the 'SESSION_HANDLER_HOST' constant to an IP rather than a hostname.



When i did this my requests per second jumped from 55 to 389 requests per second!

darkelf79 at gmail dot com
21-Jan-2006 07:00


If you set the session_id through the calling URL, it *will not* set the session cookie in 4.4.2.



For example:



www.example.com/?PHPSESSID=foo



This will set the session id to 'foo' but it won't actually set the session cookie. The last known version I'm aware of is 4.3.3 where it will set the cookie.



This doesn't appear to be definitively mentioned in here anywhere. But according to the devs, it's not a bug. Hopefully this knowledge will help you out if you're experiencing the same problem.

pascal.fr => gmail.com
20-Jan-2006 06:24


If you have saved an object in session, you must define the class of the object before the session_start().

If you don't do that, php will not know the class of the object, and his type will be "__PHP_Incomplete_Class".



This:

<?php

session_start();



class Foo{

    var $fooVar = 'Hello world !!!';

}



$myFoo = new Foo();

$_SESSION['myFoo'] = $myFoo;

echo 'Save in session';

?>

define the Foo class and save an instance  in session.



<?php

session_start();



echo '<pre>';

    print_r( $_SESSION ); // don't know the Foo class...

echo '</pre>';

?>



will print : 



Array

(

    [myFoo] => __PHP_Incomplete_Class Object

        (

            [__PHP_Incomplete_Class_Name] => foo

            [fooVar] => Hello world !!!

        )



)

royappa at spiralfx dot com
17-Jan-2006 05:19


This is just to note that I was able to fix my problems due to the many helpful comments here.



The problem I was having was as follows:

a) I was dynamically generating a file to download

b) When the user clicked "Save" in MSIE, and then imported the download file into the application, all was well.

c) When the user clicked "Open" to directly import the file, the application would throw an error.



I believe what was happening is that the browser was not saving a local copy of the file due to the "no-store" directive, when the user clicks "Open" directly.



Therefore the examples above regarding pragma & cache-control were useful to resolving it.



Thanks for all the help. I just want to add also that the following web page was of great help to see the actual HTTP headers being sent by the web app: http://www.rexswain.com/httpview.html



Much easier than doing telnet to port 80! Hope this helps other also.    



Andrew Royappa

Ravi Chotalia
27-Dec-2005 11:12


In answer to..

-PHP SESSIONS NOT WORKING in with windows---

...solution on the session cookie path.

I am running Apache 2 and PHP 4.4.0 on a Windows XP SP2.

...

----------------------------------



It was a small mistake in my directory stucture,



I have changed from c:\temp to c:\Temp as I had directory called "temp" not "Temp".Now session is working properly in my case.



Make sure directory name is same, in windows environment too.

marou at marou dot com
23-Dec-2005 12:49


In reponse to fondman at hotmail dot com with the 4.4.0 issue with local variables replacing session variables.



It also happens in 4.4.3.  



I have a development environment set up with 5.0, and the production environment is 4.4.3.  I had set some local variables with the same name as one of my session variables.  It did the same thing you described on the production box, yet worked fine in development.



Just an FYI.

jazfresh at hotmail dot com
20-Dec-2005 10:55


The vanilla implementation of session will blindly spew back the value of the session_id that the user sends it after URL decoding it. This can be used as an attack vector, by including strings like "%0D%0ALocation:%20http://someothersite.com/%0D%0A" in the cookie. Never trust user input, always cleanse it. If you only expect alphanumerics in the session hash, reject any session_id that doesn't contain it.



<?php

if(!preg_match('#^[[:alnum:]]+$#', $_COOKIE['session_id'])) {

  unset($_COOKIE['session_id']);

}

session_start();

?>

bgshea at gmail dot com
05-Dec-2005 05:18


to johnlonely at gmail dot com



the sesion.cookie_path should be used for cookie security. The cookie_path is the path on the server for which the cookies are valid.



i.e. www.example.dom/mywepage/



if cookie_path="/mywebpage"



then



www.example.dom/someonespage/



will not have access to them. I use this parameter without problems.



I'm not saying that this will make cookies secure, but certainly others of www.example.dom will not have access to them.



However, if you have other directories say www.example.dom/niftystuff that you want the cookie to be valid for, then cookie_path needs to be "/".



This is better for servers that use the /~user/ user aliasing.

jodybrabec at yahoo dot com
30-Nov-2005 07:50


To stop PHPSESSID from appearing in the url, try inserting these two lines just before session_start() -- 

ini_set("url_rewriter.tags","");

ini_set(session.use_trans_sid, false);

djhoma at gmail dot com
26-Nov-2005 07:39


As the reference mentions the value of the register_globals variable can cause some problem if you use sessions for verification.

If GET variables are registered as global and you check whether the user is already logged in like this:

<?php

if ($_REQUEST['password'] == "right_password") {

$password = true;

session_register('password');

}

//...later on:

if ($password) {

//secure content

}

?>

Notice, that if you guess the name of the verification variable and pass it through the URL (index.php?password=true) and the register_globals is true then a script like this lets you in.

I know this is a stupid mistake, but maybe I am not the only one who made it...

So after you registered the $password var, you should check the login with session_is_registered() function:

<?php

if (session_is_registered('password')) {

//secure content

}

?>

This function cannot be fooled by GET or POST variables...



Hope it's a useful note!

jounier at ac-bordeaux dot fr
24-Nov-2005 05:35


It took me long to understand how the SID was passed when cookies are disabled, and session.use_trans_sid set to 1.

The doc says it passes through the URL, which is true, when there's no form in the page. In that case, you can see the SID in the URL.

If the page contains a form, PHP automaticaly adds a hidden field it uses to pass the SID by POST. In that case, the SID is invisible in the URL.

Hope it helps.

Bram
20-Nov-2005 12:39


[editors note]


It should be noted that it's highly recommended to store sessions for each virtual host in seperate directories or in a database.


[/editors note]





I just noticed that it's possible to access the same session through multiple apache virtual hosts.


So keep this in mind when using sessions for anything sensitive, and make sure to encrypt the data (using the mcrypt functions for example, when available).

Lachlan Hunt
10-Nov-2005 10:10


> Note:  The arg_separator.output  php.ini directive allows to customize the argument seperator. For full XHTML conformance, specify &amp; there.



Exactly the same rule applies to HTML as well, there is abolutely no reason why this should not be set to &amp; by default.  The only difference is that in XHTML, XML error handling defines that it's a well formedness error.  For HTML, error handling was not so well defined nor sanely implemented and tag soup parsers just accept it, but that doesn't make it right.



arg_separator.output *MUST* be set to either of these if you're outputting either HTML or XML:



arg_separator.output = "&amp;"

arg_separator.output = ";"



http://www.w3.org/QA/2005/04/php-session

webmaster at vampirerave dot com
07-Nov-2005 03:27


If you want to receive the functionality of session.use_only_cookies but are using a PHP version prior to 4.3.0, here's an easy way:



if (isset($_GET['PHPSESSID'])) {

  exit;

}



This assumes:



session.name = PHPSESSID



Is set in /etc/php.ini

Armando Scribano armando at scribano dot com dot ar
26-Oct-2005 02:21


//PROTEC YOUR FILES . Double CHECK



User validation login

the basic operation



login.php

<?php

//f_login save a session with user and pass

$login = f_login($_REQUEST['usuario'],$_REQUEST['clave']);

//f_login return a encrypted value

if($login)

{

 $_SESSION['login_enc']=$login;

}else{

 //incorrect user or password. 

}

?>



protected.php

<?php

//Protected page 

//check



//1 CHECK. user and password

//return encrypted session

$enc_user = f_encuser($_SESSION['usuario'], $_SESSION['clave']);



//2 CHECK the last encrypted login and compare 

if($_SESSION['login_enc']==$enc_user){

  // correct

}else{

 // incorrect

}

?>

christopher dot klein at ecw dot de
24-Oct-2005 02:26


If you have trouble with Internet Explorer 6 and non-working sessions (all session-data is lost after clicking on a link), please look user-hints for setcookie().

You have to add the following line after session_start() to get sessions working:



<?php

  // Initalize session

  session_start();

  // Send modified header

  header('P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"');

?>

lassial at hotmail dot com
23-Oct-2005 10:54


If you would like to ensure your sessions with referer checking you must use iniset() regularly, as 



"session.referer_check contains the substring you want to check each HTTP Referer for"



so there is no way PHP can automatically know which URL you are expecting, e.g. it does not assume SCRIPT_NAME or anything else. 



I had a serious problem when I tried to disable referer checking with session.referer_check = 0 which of course does not work

johnlonely at gmail dot com
12-Oct-2005 02:32


Everytime I upgrade PHP to a new version, I used to recompile the php.ini file. Everytime I create a website, I always kept the php.ini file so that in the future I would be able to retrieve some Unique properties of the php version I used. So the last php version I've seen where session is sticking is version 4.2. I've been trying for two days with no luck searching the manual and forum, when I tried something :



If you guys always fill the 

session.cookie_path = /

to somewhere you the cookies should go, then leave the fuss. You'll save two days! Leave it be!



[Session]

session.cookie_path = /



Happy sticking sessions.

jmoore at sober dot dk
06-Oct-2005 10:54


The documentation says that sessions "may" be readable by other users on the system, but since it is so trivial to do, "are readable" is a more accurate statement.



For example, this will display the contents of all sessions:



<?php



  exec("cat /tmp/sess_*", $aOutput);

  print_r($aOutput);



?>



Note: Changing sessions to use a directory other than /tmp will be harder to find, but no more secure.

akoma at t3 dot rim dot or dot jp
19-Sep-2005 06:50


If your are using UTF-8, make sure your source

code editor to do not put the BOM mark 

(unicode sign) at the top of your source code. so

it is sent before session_start() causing "headers

already sent" message on httpd error log.

vincent at bevort dot com
14-Sep-2005 08:26


---PHP SESSIONS NOT WORKING---

addition to fasteddie's solution on the session cookie path.

I am running Apache 2 and PHP 4.4.0 on a Windows XP SP2. 



Had the same problem that the cookies are saved, in my case att c:\\tmp, but not recognized at reload of the page. The session.save_path must also be set to blank.

The cookies are stored in c:\\windows\\temp.

So if You do not have activated the garbage collector You can find them there for cleanup and error solving.

php at stevegiller dot co dot uk
08-Sep-2005 05:13


If you want prevent people directly setting, for example, a logged_in session variable to bypass your checks using the url?logged_in=true system, a quick trick is to try the line



if (isset($_GET['logged_in'])) { die("Are you trying to take the mickey?"); }



before you do anything else.

I've not tested this heavily, but I'd value any discussion of its merits and potential flaws ...

henry at teddystoo dot com
01-Sep-2005 09:57


Make sure HTTP_HOST matches the url you are using on the browser. (Fix the Apache ServerName setting).

Otherwise, after saving a completed session, the next page will start a new empty session!

fasteddie at byu dot edu not_this_part
17-Aug-2005 11:43


I hope this helps someone:

---PHP SESSIONS NOT WORKING---

My sessions wouldnt ever load from disk. The sessions would start just fine, and a session file would be created and written to disk. (BTW, I'm on a win XP box, Apache 2.0.54, PHP version 5.0.4.) However, next time I loaded the page, the old session would not be used. Instead, a NEW session was created. For me, this happened no matter what computer I was using, whether it was the server (localhost) or a client (remote). A new session was created EVERY TIME I loaded the page.. it was annoying. After a few hours of googling, I gave up and decided to mess around in the php.ini file. I changed this line:

session.cookie_path = /

to this:

session.cookie_path =



Now, php sessions are loaded properly.



I havent tried many things but I think maybe it is because windows needs backslashes (\) instead of forward slashes (/), and if you just leave it blank, it turns out ok.

artistan at cableone dot net
09-Aug-2005 01:29


I rewrote adodb's session management class to work across servers with database managed sessions.  Take a look at http://phplens.com/lens/lensforum/msgs.php?id=13428

Christian Boltz <php-manual at cboltz dot de>
28-Jul-2005 07:33


Another note about session.bug_compat_42 and bug_compat_warn.



[full error message:

    "Your script possibly relies on a session side-effect which existed 

    until PHP 4.2.3. Please be advised that the session extension does 

    not consider global variables as a source of data, unless

    register_globals is enabled. You can disable this functionality and 

    this warning by setting session.bug_compat_42 or 

    session.bug_compat_warn to off, respectively."

]



The following short script causes the bug_compat_42 warning to appear.



<?php

  session_start();

  $_SESSION['var'] = NULL;

  $var = "foo";

?>



It took me an hour to find out this :-(  - so I post it here to avoid 

that more people need such a long time.



Conclusion and test results:



You'll get this warning if $_SESSION['var'] contains NULL and you assign 

anything (except NULL) to the global variable $var.



The warning will _not_ appear:

- if $_SESSION['var'] contains anything else   - or -

- if you don't use a global variable named $var

cenaculo at netcabo dot pt
25-Jul-2005 03:09


A quick answer to jentulman at NOSPAM dot jentulman dot co dot uk about the redirecting problem with sessions:

Use session_write_close before redirection thus ensure session data is correctly saved before redirection.

It worked for me in all situations of redirection.

d43m0n at shaw dot ca
19-Jul-2005 04:19


Hello,



I posted earlyer about a issue/bug with Windows servers handling sessions. If you did not read it, it was based on the fact that if you can use ini_set to re-define the session.save_path to a relitive location. PHP will instead use it as the exact location with out looking at the directory where your script is bein execute, thus to say, the session file is not created, or re-read. This of course only occurs if you use <?php reregister_id() ?>. This function is told to open the requested session file, obtain the varibles, regenerate an id for that session, create the new session file and then send the cookie header to the client, of course I did not create this function, so it may not be in that order.



The following code will generate the error that I speak of, and will not successfully generate the new session id, of course like I said above, this only accours on PHP 5 & 5.0.4 under the Windows Environment.



<?php



  define("_PATH_TMP", "./tmp");

  ini_set('session.save_path', _PATH_TMP);

  session_start(); 

  $_SESSION['sid']['obsolete'] = session_id();

  session_regenerate_id();

  $_SESSION['sid']['replaced'] = session_id();

  print_r($_SESSION);



?>



(I know that PHP may use defined constants that include '_' characters at the beggining, if it has not already, but I am taking that chance atm...)



This can simply be resolved by using the following code:



<?php

  define("_PATH_TMP", dirname($_SERVER['SCRIPT_FILENAME']) . "/tmp");

  ini_set('session.save_path', _PATH_TMP);

  session_start(); 

  $_SESSION['sid']['obsolete'] = session_id();

  session_regenerate_id();

  $_SESSION['sid']['replaced'] = session_id();

  print_r($_SESSION);

?>



As you can see it uses the uses the servers environment to assurtain the exact location to the script, then locates the next root directory of it, and then allows you to define the tmp directory.



* Of course, you dont need to use a tmp directory, and this issue only occurse when using subdirectorys, I found that the following works just aswell, but this did not fit my needs!



<?php



  define("_PATH_TMP", "./");

  ini_set('session.save_path', _PATH_TMP);

  session_start(); 

  $_SESSION['sid']['obsolete'] = session_id();

  session_regenerate_id();

  $_SESSION['sid']['replaced'] = session_id();

  print_r($_SESSION);



?>

jentulman at NOSPAM dot jentulman dot co dot uk
12-Jul-2005 04:40


Here's one for the 'session disapearing after a rediredt problem'. It's nice and simple but drove me mad for a couple of hours.

I was getting reports of users logging in apparently successfully but not actually being logged in and couldn't replicate it myself.

I had a configuration file called at the begining of my script setting defines for physical and url paths, and users with the problem were coming in on a domain alias so of course the login went fine, but then they were redirected to a different domain and the cookie was pointless.

Not very technical I know but maybe it'll stop someone having to headbang like I did.

gholyoak at courtdean dot com
22-Jun-2005 11:09


Problems with IE and Content Advisor.



It maybe obvious to some, but as its taken me over a week to sort this out, I will post it here.



If you have Content Advisor enabled in IE, it appears to quietly add an extra GET HTTP request to the root of your website.



This will get processed by your default document, so if your default document is index.php, every legitimate request will be immediately followed by another hit to index.php with a blank query string.



If you increment something in a session, it will be the second hit that has the highest value, but the browser is showing the results of the first GET.



Its easy to see, just add a mail('youremail@address.com') at the start of your default document, turn on content advisor and see how many emails you get !



I have generated a 'pics-label' and added to the META tags on every page and this appears to make IE happy.



You can get a pics-label at www.icra.org.



Hope this helps

ng4rrjanbiah at rediffmail dot com
19-Jun-2005 02:37


The note regarding url_rewriter.tags and XHTML conformity in the manual is bit confusing; it's applicable only when we use <fieldset> tags. Refer http://bugs.php.net/13472



HTH,

R. Rajesh Jeba Anbiah

nigelf at esp dot co dot uk
16-Jun-2005 07:52


Session data is not available to an object's __destruct method as sessions are closed before the object is 'destroyed'.

Richard [at] postamble [dot] [co] [uk]
14-Jun-2005 10:44


Having to use transparent on a system where trans_sid was not compiled, I came up with the folowing ob_start handler:

<?php

function ob_sid_rewrite($buffer){

    $replacements = array(

        '/<\s*(a|link|script)\s[^>]*(href|src)\s*=\s*"([^"]*)"/',

        '/<\s*(a|link|script)\s[^>]*(href|src)\s*=\s*\'([^\'<>]*)\'/',

        );

          

   $buffer = preg_replace_callback($replacements, "pa_sid_rewriter", $buffer);



   $buffer = preg_replace('/<form\s[^>]*>/',

        '\0<input type="hidden" name="' . session_name() . '" value="' . session_id() . '"/>', $buffer);

        

   return $buffer;

}



function pa_sid_rewriter($matches){

    $buf = $matches[0];

    $url = $matches[3];

    $url_orig=$url;

    if ($url[0]=='/' || $url[0]=='#' || preg_match('/^[A-Za-z0-9]*:/', $url))

        return $buf;



    $ses_name = session_name();

    if (strstr($url, "$session_name="))

        return $buf;

    

    $p = strpos($url, "#");

    $ref = false;

    if($p){

        $ref = substr($url, $p);

        $url = substr($url, 0, $p);

    }

    if (strlen($url)==0)

        return $buf;

    if (!strstr($url, "?"))

        $url.="?";

    else

        $url.="&amp;";

    $url.=session_name() ."=".session_id();

    if($ref)

        $url.=$ret;

    return str_replace($url_orig, $url, $buf);

}

?>



It adds a field to urls and a fake form entry.



You can start the rewrite by doing the folowing at the start of the script:

<?php

function pa_set_trans_sid(){

    if ( defined('SID') ){ // use trans sid as its available

        ini_set("session.use_cookies", "0");

        ini_set("session.use_trans_sid", "true");

        ini_set("url_rewriter.tags", "a=href,area=href,script=src,link=href," 

. "frame=src,input=src,form=fakeentry");

    }else{

        ob_start('ob_sid_rewrite');

    }

}

?>

budfroggy a.t. adminmod d.o.t org
27-May-2005 02:21


For those of you run into sess_deleted files in your temp session directory, and have users complaining that they cannot log off, the cause is almost always due to the user's system time being off. Make sure that the user properly sets his or her time, date and time zone.



As a side note, if two users have system times set in the past, and both log onto a system, they will share the same sess_deleted file, which means that their identities could very well be swapped, leading to possible security breachs. I am going to look into code that might forcefully prevent this form happening.

Carlos Aya
18-May-2005 06:29


An bug of my own zoo that was hard to catch with sessions.



This may save time to someone else:



// in some page, after session_start

$_SESSION[$var] = $someValue; 

// my bug: $var was wrong, as it didn't contain a valid PHP identifier.

$_SESSION['flag'] = 'here'; // flag is a valid PHP identifier... but...

// then redirect to another page with session_id and everything else ok



. . .

// in next page after session_start()

count($_SESSION) == 0 

// ! yes, it's empty, as $var was wrong, that stoped the whole 

// $_SESSION array to be stored



hope this saves time to others.

frank723 AT gmail DOT com
03-May-2005 10:27


Here is a script a made to initialize global variables when both GET and SESSION variables are defined. This is common when SESSION variables retain information that is changed by a GET value. For example, when a user selects a style, the url is tagged with ?style=STYLETYPEONE, so $_SESSION['style'] should be set to the get. However, if no get is set then the session variable should remain what it was. If the session variable isnt set either, then it should be set to the default value of the variable.



Here is the code:



# a session helpful thing, start a session, with default session values

# if get for that var is set set the var to th get otherwise use session

session_start();

$ses_vars = array('var1'=>var1defaultvalue, # list of passed get vars

   'var2'=>var2defaultvalue, 

   'var3'=>var3defaultvalue);

foreach ($ses_vars as $var=>$default) {

   if (!isset($_SESSION[$var])) $_SESSION[$var] = $default;

   if (!isset($_GET[$var])) ${$var} = $_SESSION[$var];

   else ${$var} = $_GET[$var];

}



-Frank

http://entelekheia.net

origami HAT cats.ucsc.edu
04-Apr-2005 06:57


Providing the enctype attribute of text/plain in a form tag causes the form submission to result in the _POST scope not being defined.

webmaster at paginadespud dot com
29-Mar-2005 01:10


hi all,

i've been troubles with sessions at my production server for weeks and today i've noticed the problem.



If you use /tmp as php sessions file dir, on a procuction server, system garbage will delete randomly files when a certain number os files are stored at tmp, so some sessions are deleted within 1 seconds, like my case.



Solution? use another dir for php sessions file, and be careful of using a shell script for your own garbage collection, called from cron, with this line:

cd /path/to/sessions; find -cmin +24 | xargs rm



Spud.

anders
02-Mar-2005 10:15


It's true that session variables are stored on-server, but for the server to know which session the user is using, a cookie is used. If you check your cookie cache, you'd see that the only session-related information you find in your cookie is a session id, no matter how much information you store in $_SESSION.

mat3582 at NOSPAM dot hotmail dot com
28-Feb-2005 06:36


Outputting a pdf file to a MSIE browser didn't work (MSIE mistook the file for an Active-X control,

then failed to download) untill I added

<?php

ini_set('session.cache_limiter',"0");

?>

to my script. I hope this will help someone else.

trev at beammeupnowplease dot com
04-Jan-2005 12:09


You can't turn off session.use_trans_sid on an individual script basis until PHP5. 





However, if you use ini_set('url_rewriter.tags', ''); at the top of your script this will stop the SID being written to the URL's in PHP4. 





Hopefully will save someone else a frustrating couple of hours. 





Trev

jphansen at uga dot edu
23-Dec-2004 11:23


If you assign a session subscript/key to the same name as a variable, the session variable will be volatile and lost upon navigating.



For example, if passing a setting that you want in $_SESSION, don't do this:



<?

$setting = $_REQUEST['setting'];

if (!empty($setting))

    $_SESSION['setting'] = $setting;

?>



Instead, rename $setting or $_SESSION['setting'].

Xenon_54
20-Dec-2004 02:27


The session support does not use the IP address for validation. It is based on cookies and URL rewriting.



The reason you lose your session when closing your browser and reconnecting to your ISP (so you are changing your IP), is that sessions are only valides for the visit on your web site, not more.



Changing your IP address will not affect your session except if you close your browser.

Michael Wells
23-Nov-2004 01:04


If you are trying to share sessions across a cluster of servers, and don't want to use NFS, or a relatively heavy and slow RDBMS, there is an excellent tool called ShareDance that can do it over a simple TCP protocol. ShareDance comes complete with a PHP interface example and works 'out of the box' for me.



http://sharedance.pureftpd.org/



My thanks to Frank Denis for writing this elegant, valuable piece of software.

Audun Rundberg
15-Nov-2004 12:50


If you're using header('Location:' . $url) to redirect the user to another page, you should use session_write_close() to save session data before the redirect. $_SESSION is normally serialized and written to the harddrive when the script ends.



Example:



<?php



$_SESSION["Message"] = "The task was completed.";

session_write_close();

header('Location:' . $_SERVER["PHP_SELF"]);



?>



Without session_write_close(), this next piece of code would not output "The task was completed". (Assuming that this code is in place where the user was redirected.)



<?php



echo $_SESSION["Message"];



?>

irm at in3activa dot com
14-Sep-2004 02:57


Warnings :

session.bug_compat_42 and bug_compat_warn



Warnings may appears even if your code is correct, 

because some asumptions of the developpers.



In practice, these warnings are automatic when your code results in something like: 



$_SESSION['var']= NULL; 



That is, the code assume that the programmer tried

to assign a unavailable (=NULL) variable because 

register_globals is off. 



Solution: assign anything but NULL. For example:



$_SESSION['var']= is_null($var) ? 0 : $var;

cryogen AT mac dot com
10-Sep-2004 08:02


Although this IS mentioned in the PHP manual, it is not very clear and can lead to some very hard to track down bugs.



When REGISTER_GLOBALS is ON on a server, local variables of the same name as a session variable can leak their values into the session during a POST or GET.



For example, if you run script "SESS_TEST1.PHP" below, the local var $animal will bleed its value of "I am an Elephant" into the session variable $_SESSION['animal'], which should have a value of "I am a Monkey".  Beware!



<?php

// SESS_TEST1.PHP

session_start();

$_SESSION['animal'] = 'I am a Monkey';

$animal = 'I am an Elephant';

$value = 249;



echo "<script>window.location=\"sess_test2.php".

  "?animal=$animal&value=$value\"</script>";

?>



<?php

// SESS_TEST2.PHP

session_start();

$animal = $_REQUEST['animal'];

$value  = $_REQUEST['value'];



echo "SESSION['animal'] = ".$_SESSION['animal']." (should say \"I am a Monkey\")<br/>";

echo "\$animal = ".$animal."<br/>";

echo "\$value = ".$value."<br/>";

?>

Dopey
03-Sep-2004 02:06


Be careful when using the Content-Length header with session.use_trans_sid enabled. Technically, it might not be a bug, but PHP does not update the header when it adds the session ID to links in a page. The result is that only partial content is shown in a browser.



In short: if you use ob_get_length to figure out Content-Length, turn session.use_trans_sid off!

root[noSPAM]cyberdark.net
17-Aug-2004 11:55


A common problem with session.auto_start, when activated in php.ini file, is the fact that if you've php objects inside the session classes must be loaded before session in started. You'll run into trouble then...



To avoid this, if you cannot ask your sysadmin to modify the php.ini file, add this line to your .htaccess wherever you need it in your application (usually on top of your app):



php_value session.auto_start 0

bcage at tecdigital dot net
24-Jun-2004 04:24


[Quote]

Someone posted a message here saying you should just all use the MM shared memory management for sessions.  I'd like to CAUTION EVERYONE against using it!

 

I run a few webservers for a webhosting company, and we quickly ran in to PHP pages segfaulting Apache for unknown reasons, until we did a test with sessions.  It turns out that the sessions, while using the mm stuff, couldn't keep the data right.  I guess it was to do with the file locking issue mentioned in the documentation here (I didn't notice this until now!).

 

 Anyways, if you run a Unix machine that can map virtual memory to a mount point (like tmpfs or shm or whatever it may be called), use this instead.  It's volatile like mm, but works.  Only thing you don't get is hidden session info so that other people don't know how to open it easily - but it's better than trying to use mm and having the webserver crash all the time! 



[EndQuote]



You're totally right, in my server (FreeBSD 5.2) when using mm to handle sessions, dotProject wouldn't even start, it crashed when accessing index.php. This was solved by creating a swap-backed memory disk with the following options



rw,-s60000,,-b=4096,-f=512,-i=560,-c=3,-m=0,nosuid,nodev,nosymfollow

schulze at telstra dot com dot not dot this dot bit
06-Jun-2004 07:10


sessions not sticking and cookies not setting with IE? took me ages to find the problem.



you need a 'compact privacy policy'! it's not hard once you know how! 



this was too much for me: http://www.w3.org/TR/P3P/



but http://www.sitepoint.com/article/p3p-cookies-ie6/2 is very easy to apply



and a visit to this site is very worthwhile: http://www.privacycouncil.com/freep3pfix.php



happy PHP to all!



Erich

Osmos
09-May-2004 09:13


Note to the massage from "setec at freemail dot it" (01-Mar-2004 01:41).



For more flexibility I suggest replacing the string



<?php

_safe_set ($parse_url["scheme"], "http");

?>



with the following one:



<?php

_safe_set ($parse_url["scheme"], $_SERVER["HTTPS"] ? "https" : "http");

?>

Afternoon
05-May-2004 03:28


I found a good solution to create a persistent session by storing a persistence flag, ironically, in the session itelf. I start the session (which sends a Set-Cookie with no expiry time), read the flag and then, if the user wants a persistent session, stop and restart the session with the expiry time set using session_set_cookie_params, which then sends a cookie with a good expiry time. This solution has been quickly tested with all major browsers and seems to work.



I have outlined the whole process in my blog: http://aftnn.org/journal/508

Rikahs Design
14-Apr-2004 03:10


When setting url_rewriter.tags parameter in php.ini, make sure that you put quotes around the string portion like this:



url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"



or the PHP won't know what tags to insert the session id into.  My web host has a relatively current version of PHP and they still didn't have this parameter configured by default.

setec at freemail dot it
02-Mar-2004 05:41


This is a usefull code I have done that allows to make a redirection using headers with full support for sessions and HTTP 1.1.



<?php

    function session_redirect ($url = "") 

    {

        function _safe_set (&$var_true, $var_false = "") 

        {

            if (!isset ($var_true))

            { $var_true = $var_false; }

        }



        $parse_url = parse_url ($url);

        _safe_set ($parse_url["scheme"], "http");

        _safe_set ($parse_url["host"], $_SERVER['HTTP_HOST']);

        _safe_set ($parse_url["path"], "");

        _safe_set ($parse_url["query"], "");

        _safe_set ($parse_url["fragment"], "");

        

        if (substr ($parse_url["path"], 0, 1) != "/")

        { 

            $parse_url["path"] = dirname ($_SERVER['PHP_SELF']) . 

                           "/" . $parse_url["path"]; 

        }

        

        if ($parse_url["query"] != "")

        { $parse_url["query"] = $parse_url["query"] . "&amp;"; }

        $parse_url["query"] = "?" . $parse_url["query"] . 

                         session_name () . "=" . 

                        strip_tags (session_id ());

        

        if ($parse_url["fragment"] != "")

        { $parse_url["fragment"] = "#" . $parse_url["fragment"]; }

        

        $url = $parse_url["scheme"] . "://" . $parse_url["host"] .

             $parse_url["path"] . $parse_url["query"] . 

             $parse_url["fragment"];

        

        session_write_close ();

        header ("Location: " . $url);

        exit;      

    }

?>

gzink at zinkconsulting dot com
03-Dec-2003 06:57


[Editors note: I've just benchmarked this, and over a 100 element array the results are as follows: (average over 10 runs)





Standard Array: 0.102ms


$_SESSION: 0.197





This is in the extremely unlikely case of having to loop through 100 elements in a session variable. Remember, if you have that many elements in your session, something is wrong.]





A small warning! $_SESSION can be slooowwwww....





I've never heard of this, but it turns out $_SESSION is much slower than any regular array, even an exact copy of $_SESSION. Copying large amounts of data in/out of $_SESSION is seriously slow and each access to $_SESSION is noticeably slower than regular arrays.





The lesson I learned? Don't use $_SESSION in loops that run very much. Even copying data from $_SESSION before the loop won't help a lot if there's a lot of data there due to a delay that can be pretty hefty, almost equal to working directly on $_SESSION with foreach() and actually slower than working directly on $_SESSION if you need to put the data back in the array in my experience. It's better to pass the data another way if possible, i.e. save the SQL query and re-run, store in a database, etc. 





Just a warning for those who may be using this array in medium to large loops or trying to pass lots of data. I hope it saves you the hours of optimizing I've had to spend!





-Galen


http://www.zinkconsulting.com/

pautzomat at web dot de
20-Nov-2003 04:05


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:



$sHomeDirectory = 'http://my.server.com/one/of/my/projects'



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 ;)

orion at dr-alliance dot com
09-Aug-2003 06:52


Session ID's wont be carried over through meta refreshes, so make sure you add the variables (in GET format) to the URL.

IE )

<meta http-equiv=\"refresh\" content=\"1;URL=index.php?PHPSESSID=$PHPSESSID\">

tim at digicol dot de
05-Feb-2003 02:14


Be careful when using ini_set to change the  session.gc_maxlifetime value locally for your script:



You will trash other people's sessions when garbage collection takes place (and they will trash yours) regardless of their (your) intended session.gc_maxlifetime, because the session_name is not taken into account during garbage collection.



Create an own directory and set session.save_path to it, so that your session files don't get mixed.

jmgonzal_NOSPAM_at_NOESPAM_netred_DOT_cl
13-Oct-2002 06:43


If you have problem to download a file from your PHP , and you have IE (any version) and apache for server with SSL, check the reference of: session-cache-limiter



My best solution is change the php.ini from



session.cache_limiter = nocache



to:



session.cache_limiter = private, must-revalidate

twocandles3000@hotmail
15-May-2002 02:34


Storing class instances in session.





As long as a class MUST be declared BEFORE the session starts and unserializes the session info, i'm using this approach.





0: Set in php.ini session.auto_start = 0


1: create myclass.inc where the class is declared.


2: put in another file, say header.inc, this lines of code:


include_once( "myclass.inc" );


session_start();


3: set in php.ini the auto_prepend_file= "path_to_my_file/header.inc"





Following this steps, the session is started at every page and myclass is always available, avoiding to write the session_start() function at every page.

stoiev at ig dot com
21-Mar-2002 01:10


Carefull when you are working in PHP with WML. The arg separator used to put de PHPSESSID variable in URL is '&' by default, and this cause a Compile Error in browsers:



<anchor><go href="index.php?estate=1&PHPSESSID=12345678abcde"></go>



instead of this:



<anchor><go href="index.php?estate=1&#38;PHPSESSID=12345678abcde"></go>



Its safety include the line:

ini_set ( "arg_separator", "&#38;");



to change the arg separator, it worked in PHP 4.1.2



Another thing that the onpick tag is not defined in the url_rewriter.tags list by default(if there are others, i dont now). This is must be added in php.ini file.



* In most case the WAP GateWay accepts cookies an the auto-transpass-SID is not necessary, its hard to find problems with this.

ricmarques at spamcop dot net
16-Oct-2000 08:16


Regarding session.cache_limiter :





For those of you who - like me - had trouble finding the meaning of the possible values (nocache, public and private), here's the explaination taken from the HTTP 1.1 Specification at


http://www.w3.org/Protocols/rfc2068/rfc2068








"14.9.1 What is Cachable





[snip]





public


  Indicates that the response is cachable by any cache, even if it would normally be non-cachable or cachable only within a non-shared cache. (See also Authorization, section 14.8, for additional details.)





private


  Indicates that all or part of the response message is intended for a  single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache may cache the response.





  Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content.





no-cache


  Indicates that all or part of the response message MUST NOT be cached anywhere. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.





  Note: Most HTTP/1.0 caches will not recognize or obey this directive."

shanemayer42 at yahoo dot com
20-Aug-2000 10:11


Session Garbage Collection Observation:





It appears that session file garbage collection occurs AFTER the current session is loaded.  





This means that:


even if session.gc_maxlifetime = 1 second, 


if someone starts a session A and no one starts a session for an hour,  that person can reconnect to session A and all of their previous session values will be available (That is, session A will not be cleaned up even though it is older than gc_maxlifetime).

add a note