My thanks to those of you who've read this column and let me know that it's actually helped. Even more thanks to those who've sent in questions - keep them coming! Here are some of the most recent ones.

Q: I need to create a server-wide variable, not a session variable. It cannot be user specific. Can this be done without using a table?
A: Most certainly! That's what the server variable scope is used for. Most programmers just starting out with CF quickly discover how to use session and application variables, but the server variable is often overlooked. All you need to do is set a variable with the server prefix (i.e., <CFSET Server. YourVar = "Some Value">). Once the variable is set, it's stored in the server's memory and is available to all CF pages running on that server.

Q: I've installed CF Server (professional version) on my Win98 machine running MS Personal Web Server. When I try to browse any of my CF pages, the actual CF code shows up in the browser, but none of it actually executes. What have I missed?
A:This is a common problem when installing CF with PWS. The problem is CF doesn't have permission to execute the pages through PWS. The good news is it's easy to fix. All you need to do is launch the PWS administrator and assign execute rights for your wwwroot subdirectory. You can do this by editing the directory properties.

Q: What does the SETDOMAINCOOKIES attribute of the <CFAPPLICATION> tag do?
A:You really need to worry about this attribute only if you're running CF in a clustered server environment. It's used in the same sense as the DOMAIN attribute of the <CFCOOKIE> tag. Basically, cookies are server-specific, which means that a cookie will be sent back only to the server that sent it. For example, if your server (shop.yourdomain.com) writes a cookie, the user's browser will return that cookie only to the server that created it (shop.yourdomain.com). If you need cookies to be returned to any server in your domain (???.yourdomain.com), you need to set "Domain-level" cookies.

The SETDOMAINCOOKIES="Yes" attribute of the <CFAPPLICATION> tag makes the two cookies (CFID and CFTOKEN) that are used for session and client variable management domain cookies to allow for session and client variable management across a cluster of servers.

Q: I need to pass a product ID along the URL, but I don't want the user to know what the value of the ID is because I don't want them to be able to modify the URL value and view other products. Is there a way to keep people from changing a URL variable value or a way to hide it from them?
A: The answer is both yes and no. No, you can't keep someone from modifying a URL string, but you can write your code so he or she doesn't really know what's being passed along the url. There are many different ways to do this but perhaps the easiest is to encrypt your URL string so the user doesn't know what's being passed. It's a two-step process. First you need to encrypt the URL variables, then you need to decrypt them so your code on the other side understands what was passed to it. Use CF's Encrypt() and Decrypt() functions.

Listing 1 shows the code for List.cfm, which runs a query and displays product names to the user. Each product name has a link to Details.cfm (see Listing 2) and passes the product ID (in an encrypted format) along the URL. Notice the use of the URLEncodedFormat() function wrapped around the Decrypt() function. This is required because the characters generated by the Encrypt() function may not be valid URL characters. Listing 2 shows how to decrypt the value and use it in a query. The most important part to encrypting and decrypting is to use the same "key" value for both functions.

Please send your questions about ColdFusion (CFML, CF Server, or CF Studio) to AskCFDJ@sys-con.com.

• Source Code