View comments | RSS feed

cfapplication

Description

Defines the scope of a ColdFusion application; enables and disables storage of Client variables; specifies the Client variable storage mechanism; enables Session variables; and sets Application variable timeouts.

Category

Application framework tags

Syntax

<cfapplication 
name = "application_name"
loginStorage = "cookie" or "session"
clientManagement = "yes" or "no"
clientStorage = "datasource_name" or "Registry" or "Cookie"
setClientCookies = "yes" or "no"
sessionManagement = "yes" or "no"
sessionTimeout = #CreateTimeSpan(days, hours, minutes, seconds)#
applicationTimeout = #CreateTimeSpan(days, hours, minutes, seconds)#
setDomainCookies = "yes" or "no"
scriptProtect = "none", "all", or list>

See also

cfassociate, cferror, cflock, cfmodule; Application.CFC Reference; Designing and Optimizing a ColdFusion Application and Integrating J2EE and Java Elements in CFML Applications in ColdFusion MX Developer's Guide

History

ColdFusion MX 7: Added scriptProtect attribute

ColdFusion MX 6.1: Added loginStorage attribute

ColdFusion MX:

Attributes

Attribute Req/Opt Default Description

name

See Description

 

Name of application. Up to 64 characters.

For Application and Session variables: Required.

For Client variables: Optional

loginStorage

Optional

cookie

  • cookie: store login information in the Cookie scope.
  • session: store login information in the Session scope.

clientManagement

Optional

no

  • yes: enables client variables.
  • no

clientStorage

Optional

registry

How client variables are stored:

  • datasource_name: in ODBC or native data source. You must create storage repository in the Administrator.
  • registry: in the system registry.
  • cookie: on client computer in a cookie. Scalable. If client disables cookies in the browser, client variables do not work.

setClientCookies

Optional

yes

  • yes: enables client cookies.
  • no: ColdFusion does not automatically send CFID and CFTOKEN cookies to client browser; you must manually code CFID and CFTOKEN on the URL for every page that uses Session or Client variables.

sessionManagement

Optional

no

  • yes: enables session variables.
  • no

sessionTimeout

Optional

Specified in Variables page of ColdFusion Administrator

Lifespan of session variables. CreateTimeSpan function and values in days, hours, minutes, and seconds, separated by commas.

applicationTimeout

Optional

Specified in Variables page of ColdFusion Administrator

Lifespan of application variables. CreateTimeSpan function and values in days, hours, minutes, and seconds, separated by commas.

setDomainCookies

Optional

no

  • yes: uses domain cookies for CFID and CFTOKEN cookies and for all Client variables when using cookies for client variable storage. Required for applications running on clusters.
  • no: uses host-specific cookies for CFID, CFTOKEN, and all client variable cookies.

scriptProtect

Optional

Determined by ColdFusion MX Administrator Enable Global Script Protection setting

Specifies whether to protect variables from cross-site scripting attacks

  • none: do not protect variables
  • all: protect Form, URL, CGI, and Cookie variables
  • comma-delimited list of ColdFusion scopes: Protect variables in the specified scopes.

For more information, see Usage.

Usage

This tag is typically used in the Application.cfm file, to set defaults for a ColdFusion application.

Note: You can also set the application defaults in the Application.cfc file. For more information, see Application variables.

This tag enables application variables, unless they are disabled in the ColdFusion Administrator. The Administrator setting also overrides the sessionManagement attribute. For more information, see Configuring and Administering ColdFusion MX.

If ColdFusion is running on a cluster, you must specify clientStorage = "cookie" or a data source name; you cannot specify "registry".

ColdFusion generates an error if the application name is longer than 64 characters.

The CFTOKEN variable is 8 bytes in length. Its range is 10000000 --99999999.

Note: If you specify ClientStorage=cookie, any Client scope variables set following a cfflush tag are not saved in the Client browser.

Protecting variables from cross-site scripting attacks

The ScriptProtect attribute lets you protect one or more variable scopes from cross-site scripting attacks, where a client attempts to get your application to send malicious code back to a user's browser. In these attacks, user input (for example, from form fields or from URL variables) sets a CF variable which is destined for user output. The submitted data includes malicious code, such as JavaScript or an applet or object reference, which then executes on the user's system.

Note: The ColdFusion MX Administrator Settings page Enable Global Script Protection option determines the default script protection setting. You can use the scriptProtect attribute to override the Administrator setting. You can also use the Application.cfc initialization code to set the protection value.

The ColdFusion MX cross-site scripting protection operation is done when ColdFusion MX processes the application settings at the beginning of a request. Thus, it can process the URL, and Cookie, CGI, and Form variables in a user's request. By default, it replaces occurrences of the following tag names with the text InvalidTag: object, embed, script, applet, and meta. It allows these names in plain text, replaces the words if they are used as tag names.

You can specify any or all ColdFusion scopes for protection, but only the Form, URL, CGI, and Cookie scopes have variables that are often provided by unknown sources. Also, protecting a scope requires additional processing. For these reasons, the all attribute value applies protection to only the four scopes.

The script protection mechanism applies a regular expression that is defined in the cf_root/lib/neo-security.xml file in the server configuration, or the cf_root/WEB-INF/cfusion/lib/neo-security.xml file in the J2EE configuration to the variable value. You can customize the patterns that ColdFusion replaces by modifying the regular expression in the CrossSiteScriptPatterns variable.

Locking server, application, and session variables

When you set or update variables in the server, application, and session scopes, use the cflock tag with the scope attribute set to the following value:

In some cases, you should also lock code that reads variables in these scopes. For information about locking scopes, see cflock.

Example

<!--- This example shows how to use cflock to prevent race conditions during data updates to variables in Application, Server, and Session scopes. --->
<h3>cfapplication Example</h3>
<p>cfapplication defines scoping for a ColdFusion application and enables or disables application and/or session variable storage. This tag is placed in a special file called Application.cfm that automatically runs before any other CF page in a directory (or subdirectory) where the Application.cfm file appears.</p>

<cfapplication name = "ETurtle" 
sessionTimeout = #CreateTimeSpan(0, 0, 0, 60)# 
sessionManagement = "Yes">

<!--- Initialize session and application variables used by E-Turtleneck. ---> 
<cfparam name="application.number" default="1">
<cfparam name="session.color" default= "">
<cfparam name="session.size" default="">

<cfif IsDefined("session.numPurchased") AND IsNumeric(trim(session.cartTotal))>
<!--- Use the application scope for the application variable to prevent race condition. This variable keeps track of total number of turtlenecks sold. --->
   <cflock scope = "Application" timeout = "30" type = "Exclusive">
   <cfset application.number = application.number + session.numPurchased>
   </cflock>
</cfif>

<cfoutput>
E-Turtleneck is proud to say that we have sold #application.number# turtlenecks to date.
</cfoutput>
<!--- End of Application.cfm ---> 

ColdFusion 9 | ColdFusion 8 | ColdFusion MX 7 | ColdFusion MX 6.1 | ColdFusion MX | Forums | Developer Center | KnowledgeBase | Bug Reporting

Version 7

Comments


pete_freitag said on May 17, 2005 at 9:55 AM :
FYI - scriptprotect does not filter out all possible XSS attacks
" The scriptprotect attribute is meant to supplement to best-coding practices;
it provides an easy way to filter out certain tag names, but is not meant to
be a comprehensive solution against XSS attempts."
Robin Hilliard said on Jul 7, 2005 at 1:04 AM :
You should note that (in CF7 at least) the name attribute is case sensitive.
yoinky said on Sep 28, 2005 at 2:03 AM :
HUGE Pain-In-The-Ass Solution:

DO NOT USE HYPHEN CHARACTERS IN THE NAME="" ATTRIBUTE!

Just incase you are pulling your hair out wondering why your client management isn't working (like I've been doing for the past week) and have gone through everything and can't get it working on a database or in the registry, head this very simple "rule" left out of the documentation.

if you do use a hyphen, at the end of the request when the client scope is supposed to be automatically persisted by the runtime, it will display a "500 NULL" error in html at the bottom of the page, it won't even throw a real exception or log the error, so you have no idea it happened.
yoinky said on Sep 30, 2005 at 1:04 AM :
A follow up to my last post, if you enable client management, and then somehow delete the #client.hitCount# variable (for example by doing #structDelete( client )#) then the client data will fail to persist whenever changes are made!

This error wont through an exception, it wont log the error, it will simply append a snippet of html to the output with "500 null"

Any other built in client variable can be removed except for HitCount, so be careful.
Holger L said on Nov 12, 2005 at 7:06 AM :
I've been pulling my hair out because of the problem with "500 null" displaying. I have an application where I use structclear(client) on logout. I simply added <cfset client.hitcount = 1> after the StructClear, and problem was solved.
*** Tyson *** said on Sep 29, 2006 at 4:47 PM :
Confirmed here as well. We were getting "500 null" errors that were seemingly random across our 11-server application cluster. After some digging and testing and debugging, I managed to determine that the "500 null" error was only occuring when a user logged out of our application. In picking apart the logout() function, I realized we were also utilizing structClear(client) as well as structClear(cookie) to wipe out the user's client variables. When this executed, I noticed that the "500 null" errors would begin. Only way to resolve them was to restart the CF app server instance on whichever node had been corrupted by a call to this function. That behavior got me thinking that maybe something about using structClear(client) was causing issues with ColdFusion. That's then I found this set of comments, made th recommended change of adding a "client.hitcount=1;" after clearing the client struct, and our "500 null" errors have now completely vanished!

Adobe, PLEASE note this as a bug and correct this behavior in the next updater.

Tyson Vanek

 

RSS feed | Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/coldfusion/7/htmldocs/00000217.htm