I've been adding this to my pages:
pagewithinclude.cfm
<cfinclude template = "_pagename.cfm">
_pagename.cfm
<cfif Not IsDefined("variables.included_pagename")>
<cfparam name = "variables.included_pagename" default = "1">
rest of page
</cfif>
Is there a better way in CF? Something similar to PHP's include_once?
Nope, what you've done is probably the best way to do it. Although I'd use a Request variable instead.
This question was asked in 2010 (and many answers were then or 2011). Since then, in 2012, CF10 added the optional runOnce attribute for CFINCLUDE (or its script equivalent). Marques had added a mention of that attribute in a comment on the original question, in 2016, but it could be missed as an "answer".
I was helping someone who was seeking a solution to this problem, and I found this discussion, but noticed its lack of a clear answer. (And while there may be technicalities that distinguish CF's runonce from PHP's include_once, they are close enough in concept that it seems worth pointing out, even if it may not be the exact solution to the OP's question--if they even cared, now 10 years later.)
Related
This is odd and undoubtedly just another case of my embarrassingly limited capacity for problem solving causing issues BUT - We have an API that we've been using since October of 2012. Changes are VERY few and far between (as in maybe, two or three tweaks total).
About 3 months ago is APPEARS as though this.datasource in application.cfc stopped being recognized. The server was reporting this.datasource = ''.
Does anyone have any experience with this or insight into the circumstances under which this could happen? I'm more than happy to wear the dunce hat on this one but it has nme a bit emotionally bedraggled and I just 'gotta know'...my ninja theory isn't getting much traction in the office.
I've had similar issues before. To fix it I moved <cfset this.datasource = "whatever" /> to the OnApplicationStart function in application.cfc.
After you do so, remember to reinit the application.
Strictly speaking, the this scope in Application.cfc refers to fields that are specific to the application file itself. For example, sessionTimeout, applicationTimeout, loginStorage and so on. You may loosely interpret them as the application's meta data. Fields defined with this are therefore not meant to be accessed elsewhere in the application.
Datasource is the kind of property that refers to the application. You should therefore define it in onApplicationStart as:
application.datasource
I was reading Ben Nadel's post about the isnull function and my initial thought was "wait: there's an isnull function in ColdFusion? I didn't know that! I wonder if there's one in Railo?" So I typed:
railo isnull
into google and this was the first link. In fact, a lot of my Railo searches have been to similar pages, so apparently this is something that I'm supposed to be able to read and understand. Here's my question:
Q: How do you read the Railo documentation?
I'm used to seeing words written out in sentence format like Ben's post. I mean: I can see that a lot of work went into this page, so I should try to squeeze some kind of meaning out of it... When I see for example:
Methods inherited from class java.lang.Object
equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
Does that mean anything to an applications programmer like myself, or is that a kind of internal documentation? I followed the link to the actual source code, but that's almost too much information.
Maybe I've identified a need.
You read the Railo Javadoc API the same way you read any Javadoc API.
(Though as you note this is more internal documentation and most CFML developers wont need to.)
If you want Railo's CFML documentation for isNull, you visit railodocs.org/isNull instead.
I don't know why Google isn't capable of finding the correct pages. :/
For the benefit of Google I'll also throw in these other links to the isNull documentation: http://railodocs.org/function/isnull?version=current and http://railodocs.org/index.cfm/function/isnull/version/current - they all display the same content (which may be a factor in why they're not ranked properly), so if someone reminds me later I'll bug Mark about getting the URLs canonicalised.
Railo does have isNull()
It works on variables that are not strings
It works on strings
In my experience, Railo 4.2 more or less supports CFML at the same level as ColdFusion 10. It is always useful to test. I agree that as of early 2014, Railo's documentation is lacking a certain clarity.
Do any tools exists that will scan ColdFusion source code and locate XSS vulnerabilities?
Say for example a programmer wrote something like this:
<cfoutput> This is a #url.cat#. </cfoutput>
The tool would need to locate un-sanitized code.
Update:
While all of the answers and feedback so far are accurate, none point to a tool which can be run against the source code directly.
I personally know how to write code which is xxs safe. Also I can manually find, detect and correct XXS vulnerabilities. I am looking for something automated which can scan thousands of .cfm and .cfc to automate the processes.
Probably the correct answer is that such a tool does not exists. There are companies such as VeriCode which offer a service do such things. They have an automated process which in my opinion does a horrible job because of it's inability to follow code logic.
Anyway, I'll give all +1s and at this point leave the question unanswered.
Update 2: Someone did answer that I would not find a tool, so I will mark this as accepted.
Not specific to XSS but Pete Freitag has a tool that will scan your ColdFusion server for vulnerabilities. The site is Hack My CF. I believe there is a free scan option and they also offer monthly subscription options. I think the tool includes some XSS checks as well.
If you're using ColdFusion 10, you should read this article: http://www.isummation.com/blog/day-2-avoid-cross-site-scripting-xss-using-coldfusion-10-part-1/
I don't think you'll find a tool that checks your actual code, XSS tools out there focus on the form inputs, etc. You might be able to write a script parser yourself that looks for <cfoutput> tags in your ColdFusion file and then looks to see if any of the tags mentioned are present, but trying to define a set of rules for when variables should or should not be wrapped by XSS preventing functions would be almost impossible. You really need to look at each variable and its context.
There are some things you can do in ColdFusion to prevent XSS attacks though as mentioned in the article above and this one: http://www.mindfiresolutions.com/Prevent-crosssite-scripting-attacks-in-ColdFusion-1341.php
Although not ColdFusion-specific, there are several plugins for Fiddler which can detect or hint at where XSS flaws may exist. I've tried out watcher before and found it gave me some useful pointers.
This semi-new tool, security analyzer, for the ColdFusion Builder sounds promising: http://www.adobe.com/devnet/coldfusion/articles/security-analyzer.html.
And VERACODEs scanning is much better nowadays: http://www.veracode.com/
I've been using ColdFusion 9 along with the ColdFusion on Wheels Framework for about 6 months now. I still consider myself a beginner, but I am comfortable doing most things I need to.
I recently started writing full CF Script components, and I'm loving the cleanliness of the syntax. I am disappointed to lose some of the simplicity afforded by CFQuery, CFLoop, and so on... but I can live without this for now.
Recently, a few people have mentioned that Railo has better CFScript support. I'm considering switching for that reason.
What things should I keep in mind, and how do the two platforms stack against one another in terms of functionality and ease of use?
Here are the things you need to look for as far as differences between Railo and ColdFusion. This page lists all of the things that Adobe CF has that Railo doesn't, and vice versa:
http://www.getrailo.org/index.cfm/documentation/compatibility/cfml-compatibility/
Mel,
well the easiest way to try it out is to create a mapping called "/" that points to "/" and then compile this mapping from the admin. That should give you a good result on how compatible your code is in terms of compilation.
And a good thing to consider. If you are really happy with CF9, stick with it. You never change a winning team. I am of course proud of Railo and convinced it is the best CFML engine. But I am biased and you should only consider a switch if it is really necessary for different reasons. Costs, performance, memory footprint. But again, if your system runs very well on CF9, just save the money and do something else with it.
Gert Franz
Railo Technologies GmbH
Be careful making decisions based on anecdotes! ColdFusion 9.0.1 brought even more support for cfscript:
Support for the following:
for-in construct (for arrays) in CFScript
var declaration within for loop in CFScript
Function argument metadata
Function equivalents for cfile action="upload" (FileUpload) and cffile action="uploadall" (FileUploadAll)
The following script functions have been implemented as CFCs:
dbinfo
imap
pop
ldap
feed
From:
http://kb2.adobe.com/cps/847/cpsid_84725.html
If you are doing much work with PDF generation (CFdocument) or charting (cfchart), you'll want to try these out in Railo and see how they compare to what you are currently getting with Adobe CF. When I tested charting in Railo I found the Adobe CF engine to produce much nicer looking graphs. I think the PDF engine is better in Adobe CF also.
Google does not really deliver much content (or my query sucks). Has anyone made the switch and can share the experience?
We found that when we upgraded to CF 8:
Carraige returns are stripped in plain text emails. We found we had to be explicit about line feed characters by creating a var like so <cfset CRLF = "#Chr(13)##Chr(10)#"> and inserting it in the plain text email where we needed the line feed. We eventually went to HTML emails.
Third party jar files caused problems due to the order in which jar files are loaded. Certain jar files must appear first in the java classpath as defined in cfroot/runtime/bin/jvm.config. This was a messy workaround and we have discontinued using that jar.
Also make sure to patch immediately to 8.0.1. We had a performance nightmare becuase of this issue.
Best of luck!
I haven't had any CFMX 6.1 apps to switch across, but Railo is definitely my CFML engine of choice.
Compatibility-wise, there is very unlikely to be any significant issues migrating from CFMX 6.1, and you can easily test this with the Express version - no installation required!
Railo can be stricter about certain aspects of CFML, so you might get a few errors if you exploit bugs/weaknesses with CF, but nothing really to worry about.
And, if you do get stuck on anything, the Railo mailing list is active with plenty of friendly helpful people who can help to get you going again.
We made the switch about a year ago and if you are talking about only on the code side, then the change from cf6 to cf8 shouldn't require any changes as long as your setup remains the same. One change is the way that CF handles verity collections, so if you make use of cfsearch then it might be something you look into. There are a number of improvements from cf6 that you should look to implement. The few that we have found especially helpful are cfdocument, cfimage, cfpdf, and cffeed. Here is a good link with other key points... http://www.adobe.com/products/coldfusion/upgrade/
If you are upgrading from CFMX 6.1 to Railo 3.1 almost no problems should occur. There are some things that we do not support (like CFREPORT or C++ CFX tags). Besides that it should be very easy to migrate existing CFMX 6.1 code over to Railo. By default Railo is configured to be as compatible as possible with CFMX.
There are some other things you might watch out for:
If you create a struct like this in CF: <cfset a["image.x"]> you will be able to call that variable by using the "." notation, although it's misleading. So in CF you could do <cfoutput>#a.image.x#</cfoutput> whereas in Railo you would have to write: <cfoutput>#a["image.x"]#</cfoutput>
Inside functions creating variables in the local scope that are named like scopes will work in CFMX but not in Railo. So this: <cfset var url = "whatever"> will work in CF but not in Railo.
In Railo you cannot use the application scope or the session scope before it was initialized with cfapplication. Well in CF you couldn't either but there CF will create a local variable in the variables scope called "application" or "session". This sometimes leads to confusion.
Besides these things, it should go flawlessly. If you have of course any problems, just contact our Railo Google group or us directly at www.getrailo.com
Gert Franz
Railo Professional Open Source
I'm not aware of any depreciated tags or functions from CF6.1 to CF8. CF8 has been optimized for performance so you will most likely see an improvement in your application depending on what was used.
I successfully upgraded a large application from CF4.5 to CF8 with no problems. If the application consists of pretty straight forward use of ColdFusion tags and functions, you shouldn't have much problem.
However, since the developer version is free to use, you should really setup a test environment and determine the answer to this question yourself by testing your application. All datasources, custom tags, etc will have to be migrated and tested. If any CF6.1 applications used any of the lower level java api available in some things, you may need to test that thoroughly to make sure the underlying implementation of the coldfusion hasn't changed and fix what's necessary.
As for Railo3.1, there may be some tags or functions not implemented yet. You will again need to setup a test environment and determine this yourself. Somewhere on the Railo site there should be a list of compatibilities between the difference versions of CF and Railo.