Article Preview

COLUMN

Yuma Session Management

Issue: 6.5 (July/August 2008)
Author: Brad Weber
Author Bio: Brad Weber is a co-founder of Inspiring Applications, Inc. and has enjoyed 13 years of building custom software applications for Macintosh, Windows, and the web.
Article Description: No description available.
Article Length (in bytes): 6,936
Starting Page Number: 50
Article Number: 6519
Related Web Link(s):

http://.../?sid=76f86b1f009eacef02e

Excerpt of article text...

As you may be aware, the web is inherently stateless. That means that web servers have a very short-term memory when it comes to clients from request to request -- much like the fish Dory in DisneyPixar's Finding Nemo. There is no persistent connection between the web browser and the web server. That worked fine for browsing research materials in the early days of the web. But it doesn't work well at all if you want customers to be able to buy things on a website or access password-protected resources. That's where sessions come in.

A session is something that is established between a web server and web client (e.g., browser) to effectively manage multiple requests from the same client. In order for a web server to correctly identify a particular client, that client has to send identifying information to the server with every request.

Session management is usually handled in one of two ways -- through cookies and URL parameters. You've likely seen session identifiers in site links when you browse some e-commerce sites. It is typically a randomly generated string of letters and numbers to uniquely identify your browser with each request to the server as you click links, navigating through a website (e.g., http://.../?sid=76f86b1f009eacef02e). URL parameters have one advantage over cookies -- they don't require cookies. Users can intentionally disable support for cookies in their browsers and some web-enabled devices may not support cookies. So a URL parameter may be the only way to reliably identify a visitor from page request to page request.

URL parameters have a couple disadvantages. First, as the developer, you have to ensure that every link in your site (that links to another page on your site) has the session identifier (e.g., "sid=...") appended. If you miss one, and a visitor clicks on it, her session will be lost. Second, users copy and paste links to send to their friends. If a session identifier is part of a URL that someone copies to share with others, those "others" may unknowingly hijack the original visitor's session by clicking on the shared link. Unless your server takes measures to avoid it, your server won't be able to distinguish between the original visitor and her friends and family because the session ID they pass to the server with each click of a link will contain exactly the same value.

The alternative is to implement sessions with cookies. A cookie is something that the web server sends to the client/browser with the expectation that the client will return it with each subsequent request to the server, up until some expiration deadline. To manage sessions with cookies, the server sends a request to the client to store a unique session identifier (e.g., "76f86b1f009eacef02e") in a cookie, identified by a name (e.g., "yuma_session_id"), with an expiration date and time. If the browser agrees, it will store the cookie and send the cookie back to the server with every subsequent request to that site, up to the expiration date and time.

So what happens on the server? In Yuma, you start a session for a client/browser by calling Session.Start (e.g., Session.Start "MyYumaSession") near the top of your Yuma document. Yuma will handle generating a new session ID for you and send the appropriate request to the client so that it will store the required cookie. Also, a new file will be created on the server (in the "sessions" directory) in which Yuma may store session-related values. There is a function named "Session.Started" that you can call to see whether or not there is already a session in process for the client before creating a new one. But that isn't necessary. If Yuma finds that a session already exists for the client using the name you passing in Session.Start, it won't create a duplicate. It will simply ignore the second request.

...End of Excerpt. Please purchase the magazine to read the full article.