Requirements for production ColdFusion applications





	HOME » WEB DEVELOPMENT » POLICIES Requirements for production ColdFusion applications May 10, 2006 (v.4) A. About these requirements Your department relies on your production web applications to support important business processes. The purpose of these requirements is to help ensure that your production applications are stable, scalable, and maintainable over their lifetime. As you design your application, please remember that all applications require maintenance and that the applications you create today will likely be maintained by someone else after you have moved on from your current role. Requirements are divided into two categories. All applications are expected to meet the server-critical requirements. These requirements affect the performance of the servers and Web Services may disable your applications if they fall short of these standards. The support-critical standards are highly recommended. In case of issues with your application where additional troubleshooting and support is required, there is a possiblity that the application may be deemed unsupportable due to the fact it does not meet the support-critical requirements. B. Before you begin Preparing a web application for production requires specific professional skills. Beyond general familiarity with web applications and ColdFusion, you will need the following minimum skills to complete these requirements: Understand how to define a ColdFusion application using Application.cfm and CFApplication. Understand the use of ColdFusion error trapping. Understand database design and SQL. Understand variable scoping. C. Server-critical requirements These requirements affect the performance of the servers and Web Services may disable your applications with no advance notice if they fall short of these standards. Restricted tags Some ColdFusion tags are not supported. If your application uses these tags, it cannot be hosted on our production hosting servers. CFExecute CFLog CFRegistry The use of some ColdFusion tags is restricted. Before using them in production, you must demonstrate that your use of these tags will not adversely affect the hosting environment. See the details for each tag. below. CFCollection, CFIndex, CFSearch: Document the number and size of Verity search collections you want to use. Very large collections or indexing that consumes large amounts of server time can cause problems for other applications. CFFTP: Document the remote sites you will connect to and the type of data being transferred. Frequent transfer of large files can cause problems for other applications. You may not transfer confidential data in unencrypted form to or from hosting servers. CFHTTP, CFHTTPParam: Document the remote sites you will connect to and the type of data being transferred. Frequent requests for large files can cause problems for other applications. You may not use NetID usernames and passwords in CFHTTP and you may not transfer confidential data in unencrypted form to or from hosting servers. CFLDAP: Document the directory you will connect to and the type of queries you will run. Frequent requests for large remote data sets may cause problems for other applications. CFLDAP should not be used to query the Georgetown University directory; you should use the custom tag CF_GUDirectoryLookup for this purpose. CFMail: Document the volume of mail your application will send. Frequent sending of large volumes of mail can cause problems for other applications. You may not transfer confidential data in unencrypted email to or from hosting servers. All to and from e-mail addresses should be validated. You can use the following regular expression or some other equivalent REFindNoCase("^[_a-z0-9-]+(\.[_a-z0-9-]+)@[a-z0-9-]+(\.[a-z0-9-]+)\.(([a-z]{2,3})\|(aero\|coop\|info\|museum\|name))$", variables.thisEmialAddress) Note: Do not specify a mail server, username, or password when using CFMAIL. These settings are preset on the hosting servers. CFObject: Document the purpose for which you will use this tag. Only some types of extensibility are supported; please consult the web help desk. CFPOP: Document the volume of mail your application will receive. Frequent transfer of large volumes of mail can cause problems for other applications. You may not transfer confidential data in unencrypted email to or from hosting servers. CFSchedule: Document how frequently your application will schedule tasks. Do not use CFSchedule to schedule a few tasks that always recur. We will set up these tasks for you. Defining your application Your application must have an Application.cfm file in its web root. This file should contain your global settings. You must start your Application.cfm with a CFApplication tag that provides a unique name for your application (including your department name is a good way to make sure the name is unique). Error trapping By default, ColdFusion displays a standard error page with debugging information when an error occurs. You must replace this default behavior with error trapping for your application. Your error trapping may cover specific, predictable errors but it must also handle errors you did not predict. All errors must be recorded (loggind, e-mial, etc.) and reviewed by the developer. There are several acceptable ways to trap errors: Use the CF_ErrorTrapping custom tag provided by UIS. This tag will direct users to a custom error page and gives you the option to receive email about errors as they occur. Use one or more CFError tags. If you use this approach, make sure you have a CFError tag that covers "all" errors. Use CFTry, CFThrow, and CFCatch. If you use this approach, make sure you have a CFCatch tag that covers "all" errors, or use a CFError tag in addition. Datasources and queries To be used by your application, your datasource must be registered with a datasource name. Do not use this datasource name in ColdFusion tags throughout your application. Instead, set a variable containing your datasource name and use that variable in place of the datasource name. In a typical application with a single datasource, your Application.cfm file should contain a line like this: <cfset Request.dsn = "datasource name"> and you should used this variable name in place of the datasource name like this: <cfquery name="myQuery" datasource="#Request.dsn#"> Several kinds of datasources are supported. The most common datasources are Access databases. UIS also provides SQL Server hosting and your application can connect to a hosted SQL Server database. Externally hosted databases are not supported because they may become unavailable and affect the performance of the hosting servers. You are responsible for optimizing the performance of your database. An improperly designed database may affect the performance of other applications. Some basic principles to observe include: Use appropriate data types for fields. For example, limit the length of characer fields to the length you actually need. Create indexes on fields that are used as primary keys, for sorting, or for joins. Access databases larger than about 50 MB are vulnerable to corruption and poor performance. If your database is this large, your application should probably use SQL Server. You are also responsible for optimizing the performance of qu An improperly designed query may affect the performance of other applications. Some basic principles to observe include: Cache queries that are used frequently and that rarely change their results. Use the cachedWithin attribute of the CFQuery tag. In SELECT queries, specify the names of the fields you need to retrieve rather than using SELECT *. Use the WHERE clause to limit the records returned rather than filtering out unwanted records in your ColdFusion code. Avoid joins between tables that both contain a large number of records. Avoid joins between many tables. Authentication and authorization Authentication is the process of identifying a user (usually with a username and password). Authorization is the process of determining that an authenticated user has access to a particular resource. If your application will authenticate Georgetown University users (students, employees, and/or alumni), you must design your application to work with web server authentication. This process works as follows: You select a folder within your application that will be restricted. If you have several restricted folders, it usually makes sense to place them under one folder called "restricted" or "administration." You restrict access to this folder by placing the template .htaccess file in the folder. Any user who requests a URL inside this folder (or its sub-folders) for the first time will see a dialog box in their web browser requiring them to log in using their NetID and password. All users with a valid NetID login will have access to the folder. If the user is authenticated, your application can find out the current user's NetID username (but not their password). This information is available in the CGI.remote_user variable. After authentication, you may need to perform authorization to make sure that only certain NetID users can access your resources. You have two options for authorization: For simple applications with only a few groups of users, use of the CF_GUAuthorizeUser custom tag is strongly recommended. CF_GUAuthorizeUser provides a ready-made web interface for you to manage user groups and use pre-defined groups such as "all students." For more complex applications, you will need to create your own authorization system. This typically consists of database tables defining users, groups, and their access rights. If your application will authenticate non-Georgetown users (exclusively or in addition to Georgetown users), you must design your application to authenticate these users. Some basic principles to observe include: Use of the ColdFusion security environment is not supported. You must set up your own authentication and authorization. Login forms must use SSL encryption (a URL containing https://) when submitting usernames and passwords. Passwords may not be stored in plain text. You must create a hash and compare the user's login to the saved hash. Test your application to make sure that all the resources you want to restrict access to are actually protected. Variable scopes ColdFusion provides a number of variable scopes to store different kinds of information. The Client and Session scopes can be used to maintain data specific to a client across multiple requests. To use these scopes, you must enable them in your CFApplication tag. If you are not using these scopes, do not enable them. The Application scope can be used to maintain data in memory across all client requests. It does not need to be separately enabled. If your application stores data in any of these scopes (Client, Session, Application), you must use the CFLock tag when accessing them. This is recommended by the manufacturer to mitigate the risk that the server may associate data with the wrong request. For example: <--- Store content in a session variable. ---> <cflock scope="session" type="exclusive" timeout="30" throwontimeout="yes"> <cfset Session.username = "bob"> </cflock> <--- Get content from a session variable. ---> <cflock scope="session" type="readOnly" timeout="30" throwontimeout="yes"> <cfoutput>#Session.username#</cfoutput> </cflock> D. Support-critical standards Framework A framework is a documented method for constructing an application. It provides standards for organizing your folders and files in an application and makes applications much easier to maintain. The most common framework for ColdFusion applications is called FuseBox. The use of a documented framework is highly recommended. If you do not use a documented framework, it will be unnecessarily difficult for anyone else to maintain or update your application. It will also make it very difficult for UIS to help your department if there is an emergency with your application. The contemporary versions of a framework such as FuseBox can be complex and time consuming to learn. For this reason we provide a simple framework standard that we recommend for organizing your code in the absence of an external framework. [find this link -- is this still on the web?] Security and validation You are resposible for the security of your application and the resources it contains. For example, if you are doing authentication and authorization in your application, test it to make sure it works. SQL injection is the most common security threat for web applications. SQL injection means passing SQL statements into a form or URL parameter that then become part of a SQL query in your application. To reduce the risk of SQL injection, use the CFQueryParam tag in conjunction with CFQuery. To further reduce the risk of SQL injection and to prevent users from entering data that may cause your application to behave unpredictably or crash, you should valide form values. You can do form validation using the features of CFForm, using hidden fields, or using custom validation after the form has been submitted. Validating URL parameters is also recommended. Documentation The web applications you are designing now will almost inevitably be maintained or updated by another developer in the future. A little documentation goes a long way toward helping another developer understand your application. Some basic principles to observe include: Your documentation starts with how you organize your code in folders and files. The names of your folders and files and their organization should convey the classes of content in your application and what is being done with them. A framework provides a valuable standard for naming folders and files. How you write your code is also a form of documentation. Structuring and indenting your code logically and using descriptive names for variables, tags, and methods helps yourself and others. Unless it's obvious what a template does, start the template with a few lines of comments describing its function. Scatter comments throughout your code. A comment every 5-10 lines is a good idea. Describe what's currently happening or what's about to happen. For complex processes, provide a comment that outlines the steps in the process. Provide summary documentation for your whole application. Answer obvious questions such as: What framework have you used? What exceptions have you made to the framework? What external dependecies does the application have?