Introduction to Maintaining the State of Applications with PHP Sessions - Configuring the PHP session module: using some helpful session functions
(Page 5 of 5 )
True to form, PHP also exposes a bunch of handy functions, aimed at returning and modifying some configuration parameters assigned as default values in the corresponding php.ini file. Over the next few lines, I’ll provide an overview of some of them, so you can have a clear idea of the role they play within the overall PHP session management module.
My list of examples begins with the “session_cache_limiter()” function, which returns the current setting of the “session.cache_limiter” directive, included in the php.ini file:
echo session_cache_limiter(); // default value is 'nocache'
// set new cache limiter to 'public'
session_cache_limiter('public');
echo session_cache_limiter();
// set new cache limiter to 'private'
session_cache_limiter('private');
echo session_cache_limiter();
As shown above, the “session_cache_limiter()” function allows you to return or change the settings of the “session.cache_limiter” directive. This parameter controls how server responses will be cached by the browser, and its default value is “nocache.” This means that any client/proxy caching process will be disabled by default in PHP.
On the other hand, if a value of “public” is assigned to this parameter, it will allow proxies and the client to cache content respectively. A value of “private” will disable caching by proxies, but enable caching by the client. As you may have guessed, all the cache directives are handled directly by the appropriate HTTP headers.
Now, it’s time to have a look at another handy PHP session function, in this case “session_cache_expire(),” which returns and eventually modifies the settings of the “session.cache_expire” directive:
session_start();
echo session_cache_expire();// default value is 180 seconds.
// set new cache expire value
session_cache_expire(20); // set cache value to 20 seconds.
echo session_cache_expire();
The above example shows how to use the pertinent “session_cache_expire()” function. Of course this function should be utilized when cache is enabled, and its default value is 180 seconds. If a new setting is assigned to this directive (the example sets a new value of 20 seconds for caching contents), the current value will be replaced with the new one.
Eventually, if you’re going to modify the “session.cache_expire” setting, keep in mind that the default value of 180 seconds is assigned to it with every new HTTP request, so you should change this directive each time a request is triggered and before calling the “session_start()” function.
Another helpful function that will allow you to modify the value assigned to PHP session storage modules is the “session_module_name()” function. In case you didn’t know about this feature, PHP can be configured to use different storage modules. As you saw before, the default storage module is “files,” but it’s possible to modify this setting, in order to use shared memory, by assigning a value of “mm,” or utilizing user-level callback functions, which are used in conjunction with the “session_set_save_handler()” function. For this last option, the assigned value should be “User.”
Now, here’s an example of how to use this function:
echo session_module_name().'<br />'; // default value is 'files'
// set new module name
session_module_name('user');
echo session_module_name(); // displays ‘user’
After demonstrating a simple implementation of the “session_module_name()” function, I’m going to finish (for the moment, so don’t worry) the discussion of PHP session-related functions, by explaining the combination of “session_set_cookie_params()/ session_get_cookie_params()” functions. Here’s a couple of examples that show how to use them:
$cookieparams=session_get_cookie_params();
print_r($cookieparams);
In the above script, the “session_get_cookie_params()” function is used to return the settings of the following php.ini directives: “session.cookie_lifetime," “session.cookie_path,” “session.cookie_domain” and “session.cookie_secure.” And the output I get on my browser is listed below:
Array ( [lifetime] => 0 [path] => / [domain] => [secure] => )
As you can see, the above function returns nicely the values assigned to the php.ini entries that I mentioned before. Its counterpart, the “session_set_cookie_params()” function, should be used in the following way:
session_set_cookie_params(3600,'/cookiepath/','mydomain.com');
session_start();
$cookieparams=session_get_cookie_params();
print_r($cookieparams);
And the output would look similar to this:
Array ( [lifetime] => 3600 [path] => /cookiepath/ [domain] =>
mydomain.com [secure] => )
In this case, this function sets new values for the corresponding php.ini settings, which will only be valid during the execution of the script in question. Thus, if you need to keep the new assigned values across different HTTP requests, the function should be called each time a new request is made. Simple, right?
At this point, I provided you with a pretty educational overview of some of the most important PHP functions included within the session management module. However, if you’re now thinking this is the end, I’m afraid you’re wrong. There are still more topics to be covered related to PHP sessions, so be patient and read the upcoming articles.
To wrap up
In this first part of the series, I covered the basics of the PHP built-in session mechanism, as well as some of its many useful functions. However, as I said previously, I’m only scratching the surface of PHP sessions.
Over the next article, I’ll explain a few additional PHP session functions, aimed at achieving a greater level of control over the entire session mechanism. Caught your interest? Fine, see you in the next part!
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 15 
