Tag: php

Session Locking. Some people don’t ever consider this. I have dealt with it before in another language, so I decided to do a quick search to see what it looks like in PHP.

The basic idea is that only one process can have a file open for writing at a time. Session information is kept in files, and since you can have multiple hits coming into your web page simultaneously, things have to be processed in order, in a queue. This can cause your site to slow down under heavy load.

There are techniques you can use to help speed things up.

What I found is this:

<?php
// start the session
session_start();

// I can read/write to session
$_SESSION['latestRequestTime'] = time();

// close the session
session_write_close();

// now do my long-running code.

// still able to read from session, but not write
$twitterId = $_SESSION['twitterId'];

// dang Twitter can be slow, good thing my other Ajax calls
// aren't waiting for this to complete
$twitterFeed = fetchTwitterFeed($twitterId);

echo json_encode($twitterFeed);
?>

For an explanation of what’s going on here, check out the original post at  http://konrness.com/php5/how-to-prevent-blocking-php-requests/

 

Now that I know how to enable sessions, and have a better understanding of how they work, the next thing to do will be to make use of the session in some way.

But first, here are a couple notes I found in my reading:

• The first time a user visits a page, SID will be set because the cookie doesn’t exist yet. That means that if you have the SID manually placed in your URL’s, or if Transparent SID Support is turned on, every search engine bot will pick up your links with session id’s added in.
• The setting to make it so that cookies are required for sessions is session.use_only_cookies, in php.ini
• If you need to add the SID manually in your URL’s, it *must* come first in the list of attributes, or it will not work.

So what to do with sessions? Obviously they’re used to store persistent data across multiple page loads. What that data is is up to the programmer.

To add an element to the session superglobal, do something like this:

$_SESSION['myValue'] = 1

In the next part, I’ll look at what can happen when more than one request is trying to access the session file at the same time.

Building off the previous part, I will now see what’s going on under the hood when a session is started.

One of the things I needed to figure out is what this means:

PHP is capable of transforming links transparently. Unless you are using PHP 4.2.0 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.

I searched Google, and couldn’t find a clear explanation of what “transforming links transparently” means. Nor could I find what “Transparent SID Support” means.

Transparent SID Support simply means that when this is enabled, there is no need to pass the SID in your links manually. PHP will do it for you.

So let’s see what this SID variable is all about.

First, I’ve added code to display the PHP constant “SID”. According to the manual this variable will either be a blank string, or a string having the form “session_name=session_id”. (session_name is defined in the php.ini file)

<?php

session_start();

echo '<pre>';
var_dump($_SESSION);
echo '</pre>';

echo "<br />";

echo '<pre>';
echo(SID);
echo '</pre>';

The output of this code is interesting. The first time I ran it, there appeared to be no output for SID:

array(0) {
}

I suspected that there might be a cookie involved at this point, so I took a look and found this:

So, the next thing I did was to remove that cookie, and refresh the browser. When I did, I saw this:

array(0) {
}

PHPSESSID=cuo02mq7uatkcsfhvnjvv16ac4

Now SID is outputting the session ID. So the lack of a cookie means that SID jumps into action.

Note that the session id’s are different. This makes sense. If you clear your cookies, you lose your session. If your cookies are disabled, SID will be there as a replacement. Note however that passing the SID in the URL can leave you more vulnerable to XSS related attacks.

Next, I refreshed my browser page again, and when I did, the SID output went away, and the cookie reappeared. As expected, the cookie value was the same as the SID from the previous refresh, indicating that PHP has successfully set a cookie, and will now manage the session in that manner, as long as I don’t delete it or disable cookies.

Transparent SID Support is disabled in newer versions of PHP by default because it’s not a good idea to pass the session in the URL string. Basically, if you are using sessions, you should require cookies if you want to be as secure as you can.