session| Tips | scripting session usage
PHP 4.0 has a feature that has always been expected, and this is the PHP session support. By contrast, PHP 3.0 users have to use a third party library or do not have this feature at all. The lack of session support is one of the biggest flaws in PHP, and it's one of the most criticized places. However, as session support becomes part of the latter from the early beta version of PHP 4.0, the barrier is gone.
With session support, you can maintain user-specific variables during a user's visit to a Web site without having to do something like this: Set up multiple cookies, use a hidden form field, or store information in a database that you may want to link to frequently.
Starting a session on a page tells the PHP engine that you are either going to start a session (if not previously) or continue the current session:
Session_Start ();
Starting a session sends an identity string (such as 940F8B05A40D5119C030C9C7745AEAD9) to the user via a cookie, and a temporary file that matches this is created on the server side, in this case the name is: Sess_ 940f8b05a40d5119c030c9c7745aead9. The file contains the registered session variables and their assignments.
User access counters are the most common examples of using sessions:
Start your PHP module and make sure that the PHP code is the first line of the file: No blank, no HTML output, and so on. This is because when the session function emits a file header, if you send a blank or HTML code before the Session_Start () function, the system will complain.
?
If a session does is not yet exist to this user, start one
Session_Start ();
Next, register a variable named count.
Session_register (' count ');
Registering a variable equals telling PHP that a variable named count exists as long as the session is present. This variable is not yet assigned a value. However, if you add 1 to it, the value can be assigned to 1:
$count + +;
Consider each of these lines of code together, in fact, you have started a session (if not previously), assigned a session ID to a user, registered a variable named count, and added $count 1 to indicate that the user first visited the page:
To display the number of times a user accesses a page under the current session, you simply print out the $count value:
echo "<p>you ' ve been here $count times.</p>";
The entire access counter code looks like this:
?
Session_Start ();
Session_register (' count ');
$count + +;
echo "<p>you ' ve been here $count times.</p>";
?>
If you overload the above script, you can observe that the count increases. Funny, huh?
You can also register an array in a session. Let's say you have an array named $faves:
$faves = Array (' chocolate ', ' coffee ', ' beer ', ' Linux ');
You can register the array just like any other single variable:
Session_register (' faves ');
There is no difference between an indexed array and other univariate variables, such as $faves. If your users want to display their hobbies on one page of a Web site, you can simply register what he likes as a $faves session variable, and then you can print the values on other pages:
?
Session_Start ();
echo "My user likes:
<ul> ";
while (the list (, $v) = each ($faves)) {
echo "<li> $v"; }
echo "</ul>";
?>
Here's what you'll get: A nice list of user interests.
The session variable cannot be overwritten by the query string, which means that you cannot type an instruction such as http:///www.yourdomain.com/yourscript.php?count=56 to assign a new value to the registration session variable $count. This is important for security: You can modify or delete (unregistered) session variables only on server-side scripts.
If you want to completely delete a session variable, you can unregister the variable from the system:
Session_unregister (' count ');
To completely delete a session, such as pressing the logout button is an example of this, you can write the following code:
Session_destroy ();
Using a session to store variable values allows us to avoid the pain of writing database processing code, which will not unduly increase the load on the system, but also reduce the use of proprietary database syntax, and you no longer have to send a lot of cookies to users who visit the site. And now--only need a cookie, a variable is all done, really a drop of water reflected all the glory! It can't be simpler than that.
