Warning: this site is no longer up to date. New guidelines are coming soon.
Please contact 'admin-di-dc ishosting' for any information about hosting with ColdFusion.
Due to the dynamic nature of ColdFusion pages we feel a couple of warnings are in place here:
-
Web contents that are generated on the fly are
inevitably served slower than static web pages. The
contents not only have to be generated each time
requests arrive, the generated contents cannot be
cached anywhere either.
Please, consider the use of static files where possible. Contents that change once a day or less frequently can be served faster through static pages. A hint: in some cases it is more appropriate to keep your data in an offline database and generate a new set of static pages whenever changes are required. -
Creating and maintaining CFML pages involves
programming skills. Inefficient programming is
probably the most common reason why applications
perform poorly.
Please, try to keep this in mind before uploading your CFML pages. Thorough testing is not a luxury, it is a necessity. -
Never trust input entered via HTML
forms.
Always verify input, and explicitely block out invalid information. - Information that is entered through HTML forms must not be published without prior verification by the owners of the web pages.
This chapter will describe the configuration of the
ColdFusion servers and their use on the EUROPA and
IntraComm web servers.
For more details about ColdFusion Enterprise server,
ColdFusion Studio and the use of these tools, refer to
the appropriate ColdFusion documentation, or contact 'admin-di-dc
coldfusion'.
The main web servers have been configured to allow the
execution of *.cfm pages.
Native Oracle drivers are being used to access Oracle
databases. Please refer to the chapter on 'publishing databases through
ColdFusion' for details.
ColdFusion servers
The Data Centre offers ColdFusion servers on Unix and Windows platforms. The standard environment is Unix, but for specific requirements, it is possible to use Windows environment. For dissemination applications (Europa, IntraComm), ColdFusion/Unix is our strategy.
- Under Unix
-
- a development server (cfdev)
-
a test/acceptance server (Staging).
Please, note that the staging server is a pre-publication server, not a development server. All development of, and experimenting with applications should be finished prior to uploading the applications on the staging servers. -
3 production servers (Europa, IntraComm,
cfprod)
Europa and IntraComm are mainly dedicated to dissemination purposes and apply enforced security rules. The server cfprod is used for applications which have specific requirements; its ColdFusion version is 4.5. It should be replaced in the future by a new server.
-
Under Windows (see WES web hosting).
- The WES team has developped its own web site (http://doctor.cc.cec.eu.int/wes/webhosting/index.htm), but note that it is not accessible from everywhere.
The presence of the ColdFusion Enterprise server on the development and staging servers allows the information providers to upload and test new or updated CFML pages before having them published on the production servers. The contents can be uploaded using FTP or using share folders under Windows servers.
All the ColdFusion servers (except cfprod) are in version 5.0.
They are configured using the character set "UTF-8" under Unix and "ISO-8859-1" under Windows. The next Windows/ColdFusion version will use the character set "UTF-8".
Site-wide security context
ColdFusion is a powerful tool with features that are rather problematic for sites that are accessible to the public 'at large'. We are not very keen on making features like these available per default: possibility to connect to other systems using FTP and HTTP, the possibility to read and write all kinds of files, ... .
In an attempt to reduce the risks we have set up a site-wide security context which inactivates or limits the scope of some of the ColdFusion features. Some of these features can be reactivated in controlled environments, using a security context, when necessary.
CFML tags
In principle, the CFML tags that are not available for
use on EUROPA and IntraComm are the ones that set up
TCP connections, that allow read-access to files
throughout the system and that allow direct changes to
published information (write-access).
The following CFML tags have been disabled within the
site-wide security context:
- CFDIRECTORY, CFFILE, and CFCONTENT: data should not be made visible in an uncontrolled manner (see File access).
- CFOBJECT: CORBA and Java objects should not be called in an uncontrolled manner.
- CFREGISTRY: generalised access to the registry generates an unacceptably high performance hit.
- CFADMINSECURITY: this is none of your business, is it?.
- CFEXECUTE: execution of server host commands, you can't be serious!
- CFFTP and CFHTTP: very usefull for bypassing both the editorial committees and the firewalls.
- CFPOP: POP is not used within our walls.
The use of some of these tags can be accepted within the boundaries of a security context. This should reduce the risk of problems generated by mistake and other security loopholes.
Data sources
The side-wide security context does not allow access to any data sources.
Access to files and directories
Access to the document root directories of the web servers from within the site-wide security context is impossible.
File access
The site-wide security context has been set up to prevent uncontrolled access to files and data sources. A first security measure is to prohibit all use of the CFDIRECTORY, CFFILE, and CFCONTENT tags. This makes sure nobody can access any files on the server at all.
Nevertheless, access to files and directories, using the CFFILE, CFDIRECTORY, and CFCONTENT tags, can be set up when necessary. These access rights will be restricted by the security context and resources (work spaces used).
Please note that write access to files and directories within the document root directories of the web servers will not be allowed.
Work space
For every security context a dedicated work space can
be created. All the work spaces will be located in a
separate filesystem in order to prevent a 'run-away'
application from blocking the server.
Per convention the file path for the work space will be
similar to the URL path.
For example: a ColdFusion application running under
'http://europa.eu.int/some/path/' will have read-write
access within the work directory
'/europa/public/work/some/path/'.
For applications running under IntraComm replace
'europa' with 'intracomm' and 'europa.eu.int' with
'www.cc.cec' in the preceding example. For applications
to which access is to be restricted replace 'public'
with 'restricted'.
The work space is meant to temporarily store work data. It is not meant to contain information that is to be published.
The work space cannot be accessed directly. If you need to move data from the work space to elsewhere for further processing, then you will need to include this functionality in the ColdFusion application, or set up a script (e.g. Perl) on the production server that does this for you.
Sandboxes
Not used. Because of server performance.
Data sources for Oracle DBs
Oracle data bases can be accessed from within ColdFusion applications using native Oracle drivers. For more details on Oracle data bases (software version, installation, maintenance procedures), refer to the dedicated chapter.
For our purposes we differentiate between three types of data sources:
- data sources used to make information available to the public: because this information should be made available for browsing only, we configure the corresponding data source with read-only access. This means that only 'SELECT' SQL statements are allowed for Oracle DBs that contain information that is to be published.
- data sources used to collect information: information that is collected from the visitors must not be made available to the public without explicit verification of the contents. For these data sources we will only allow the 'INSERT' SQL statement.
- data sources used for work data (e.g. user profiles): this type of information necessitates full read-write access to the data bases that store this type of information. This information must not be made directly available to the public.
Sending E-mail
The ColdFusion servers have been configured to send out
e-mail (CFMAIL). Receiving e-mail (CFPOP) is not
foreseen.
In order to prevent abuse of our servers for spamming
purposes we strongly recommend that e-mail
destinees cannot be created by the users in an
uncontrolled manner. Addresses should be pre-defined
within the application.
Also, if you include a "From:" field in your e-mail,
make sure it is a valid e-mail address. E-mails without
a valid "From:" are rejected by the mail system.
Miscelaneous set up notes
Strict attribute validation
Strict attribute validation rules will be used. Extraneous attributes will not be allowed for any tags in CFML. Strict attribute validation improves template execution time and allows for the prevention of many CFML coding errors.
Client state management
The use of external data sources is to be preferred over using cookies. Separate, dedicated, data sources with read-write access to store client profiles should be used (normal data sources should be read-only, see higher).
Application and session variables
Application and session variables have been enabled, with a 2 day default timeout for application variables and a 20 minute timeout of session variables.
Locking variables
In order to enhance data integrity we have configured
the ColdFusion servers to enforce the locking of data
that are stored in the Server, Application and Session
scopes ("full checking").
This implies that developers have to use the CFLOCK tag
and provide lock access to all variables.
One important note: you have to lock and un-lock each
variable within the same file. In other words, the
<CFLOCK ...> tag and the corresponding
</CFLOCK ...> tag have to be located within the
very same CFML file.
Timeout requests
After 30 seconds.
Working with Java
The ColdFusion servers have not been set up to use Java. The CFOBJECT Type="JAVA" tag is not supported on our Solaris platforms anyway.
Custom tags
It is possible to use custom tags. They are implemented
using:
- the default ColdFusion directory: we have to transfer
your custom tags to this dedicated directory
- your own directory under your site: we declare the
appropriate path in the ColdFusion server.
CFX tags
Not used. Because of portability, server performance and stability reasons.
Registered Java applets
Not recommended by the Information Providers Guide and therefore not configured. This implies that the CFAPPLET tag, and several other CF tags that depend on Java applets should not be used.
Verity search'2K
This search engine is not linked to the Verity
Search'97 Information Server that is used as the general search engine on our
sites. The use of this central search engine is to be
preferred.
The ColdFusion instance of the Verity Search'2K search
engine can be used within the boundaries of
applications, in cases where the central search engine
cannot give the desired results.
Please note that the central search engine does not include cfm pages in its indexes. ColdFusion pages are generated on the fly, and their contents, in principle, will change every time they are requested. It is therefore useless to include this unstable information in the search indexes.
Scheduling
Can be done by the Data Centre ColdFusion team upon request.