I am working on a lot of ColdFusion legacy code. I am seeing
<cfform action="xxxx.cfm" method="POST" enablecab="No">
I am working on retiring <cfform> but I am at a loss as to what enablecab="No" does.
QA has spotted the change, but I am at a loss as to how to describe the change. This system was recently updated from CF10 to CF2016
The enableCAB attribute was around when Java applets were still a thing and ColdFusion used them to make things such as <cfform> (and its input parts) "more rich". Enabling enableCAB prompted the user to download the required applet classes as a .cab file (Microsoft's archive format) speeding up the transfer. It was thus only available for Internet Explorer and required Microsoft's Code Signing (Authenticode).
The attribute's functionality was removed without substitution in ColdFusion MX (ColdFusion 6) back in 2001. However, the attribute is still read and completely ignored in newer versions.
Short answer:
It does nothing
Long answer:
Normally, when <cfform> gets an attribute that is not on its official list, it will do a passthrough. enablecab does not. It just disappears into the æther.
Also it does not do any kind of validation. It used to have to be truthy or falsy. But now it takes anything.
Related
These two links reference the ability, in ColdFusion, to get the name of an uploaded file using form.getPartsArray(). However I can not find ColdFusion documentation on it. I would like to use this but not if it has been deprecated or will be. Does anyone have more information on the origin and fate of this function?
ColdFusion: get the name of a file before uploading
http://www.stillnetstudios.com/get-filename-before-calling-cffile/
ColdFusion: get the name of a file before uploading
Ignoring the main question for a moment, can you elaborate on why you want to use it? Reason for asking is the title of the first question might give you a mistaken impression about what that method actually does. Form.getPartsArray() does not provide access to file information before the file is uploaded. The file is already on the server at that point, so in later versions of CF (with additional functionality) it does not necessarily buy you much over just using cffile action=upload.
Does anyone have more information on the origin and fate of this
function?
However, to answer your other question - it is an undocumented feature last I checked. (It was more useful in earlier versions of CF, which lacked some of the newer features relating to form fields and uploads.)
Internally, most form data can be handled using standard request objects, ie HttpServletRequest. However, those do not support multipart requests, ie file uploads. So a special handler is needed. Macromedia/Adobe chose to use the com.oreilly.servlet library for their internal implementation. That is what you are accessing when using FORM.getPartsArray().
The O'Reilly stuff has been bundled with CF since (at least) CF8, which is a good indicator. However, using any internal feature always comes with the risk the implementation will change and break your application. Also, if you move to another engine, the code may not be supported/compatible. So "You pays your money, you takes your choice".
CF8 / Form Scope
I'm seeing a difference in how HTMLEditFormat works in CF9 and CF10.
HTMLEditFormat(">")
In CF9: showing up as ">" (no difference)
In CF10: showing up as ">" (double-escaped, which seems correct to me)
I've looked through the CF10 notes and reviewed the HTMLEditFormat documentation, but cannot find any mention of there being a difference in how this function works. Does anyone know of a difference, or know of documentation that proves there is no difference? ...Or know of any other settings (ColdFusion or web server) that might cause this to work different?
(This question is not a duplicate because am not asking about encodeForHTML. I understand that is the ideal solution, but am asking to understand why HTMLEditFormat might be different in CF9 vs. CF10.)
I can't imagine why that function would behave differently. Especially when it's was planned for deprecation going into CF 10. By chance, are you calling it from within a CFINPUT tag?
<cfinput id="foo" value="#htmlEditFormat(someValue)#" />
If so, in CF6 - CF9, that tag uses HTMLEditFormat() on values automatically. Calling a 2nd instance of HTMLEditFormat() doesn't affect the output. But CF 10+ updated the tag to use encodeForHTML() on values. If you also throw in an HTMLEditFormat(), then you're double-encoding the output.
For better security, you should stop using HTMLEditFormat() and start using encodeForHTML() if it's available (CF10+). As of ColdFusion 11, HTMLEditFormat() has been officially deprecated and by ColdFusion 12, the function should be removed completely.
HTMLEditFormat() only encodes 4 characters: <, >, &, ".
encodeForHTML() encodes almost every character, including UTF-8 characters. The updated "encodeFor" functions are contextual, so you have to pick the right on for the right context (html, htmlattribute, js, css, xml, etc.).
In our project we got an application that uses an external configuration file (say server.xml). Now we need to design a setup tool GUI in C++/QT to read/edit such configuration file and it should be able to handle all the different versions of such file. The user will choose the file version and then proceed with the editing. From one version to another doesn't change too much, maybe there is a new xml tag, a tag with a different name or in a different position.
What's the best design approach to do so? We are planning to go for a standard MVC design pattern but how to deal with all the different configuration versions without rewriting the same GUI code again n again?
Here the sample config file:
<?xml version="1.0" encoding="utf-8"?>
<Server_configuration ver="11">
<core>
<enable-tms>true</enable-tms>
<enable-gui-messages>true</enable-gui-messages>
<waiting-for-config-timeout>10000</waiting-for-config-timeout>
<remoting>
<port>50000</port>
<join-timeout>5000</join-timeout>
<ismultithread>true</ismultithread>
<maxconcurrentrequests>20</maxconcurrentrequests>
</remoting>
</core>
<content>
<ftp>
<ip>192.168.0.227</ip>
<port>21</port>
<userid>******</userid>
<passwd>******</passwd>
</ftp>
<library>
<ip>192.168.0.227</ip>
<port>50023</port>
</library>
<local>
<asset-root>/assetroot</asset-root>
<kdm-expiration-warning>172800000</kdm-expiration-warning>
</local>
<hula-store-daemon>
<ip>127.0.0.1</ip>
<port>5567</port>
</hula-store-daemon>
</content>
</Server_configuration>
This is no means a drop in solution but I here are some things to do/consider. Every situation will differ.
Have an explicit version identifier in your config files. Fingerprinting them is a real (error prone) pain.
Consider having a tool that will update from version to version. It will be easier than reading old versions and trying to apply them.
I may be easier to do every version step individually but this can make the conversions less "lossless". A happy hybrid is to do minor updates from version to version but have "checkpoint" major upgrades that will jump right to the latest (or the latest "checkpoint"). This is kinda like incremental backups with full backup snapshots every once and a while.
Keep the user informed. A sysadmin won't be happy if you are changing his settings. You might want to make the process interactive or put comments into the file of every added/moved/removed setting. I would also recommend keeping removed settings in some section of the file for user reference. (Put a note why they are there as well).
Backup the old file. Your script will crash and it will eat data. Do something like naming the current file ${oldname}.old-${ver}~. Saving the settings in a different section of the file won't always be enough and this will save your users a lot of heartache.
Versioning should always be designed as robust and as simple as possible. It is crucial for you to determine whether each version of your application must be compatible with each version of the setup tool (which is rare), or whether you can, for example, meet your needs if any newer setup tool works with any same or older application, but not vice versa.
One way compatibility
One possibility to design for the latter is to add a version attribute to the XML file but try to keep it at the same fixed value forever by always only changing the structure and semantics of the XML file in backward compatible ways. For example, adding an element is backward compatible as long as the setup tool can interpret its absence the same way both the old setup tool and the application would behave. It does not hurt that the new setup tool always writes an (equivalent) value to the new element, because two-way compatibility with the old application is not required.
Once the day comes when you cannot maintain backward compatibility on input, you just change the value of the version attribute and start special casing it in the setup tool.
If you validate the XML against an XSD, notice that XSD can actually do one frequently useful thing for you: assign default attribute values. This way, your setup tool's source code may not even actually notice that the underlying document was missing a recently added attribute!
Two way compatibility
Strict versioning is needed. A schema definition (XSD, RelayNG,...) should be defined for each version of the XML file and the file should be validated against it both when it is read by the setup tool, written by the setup tool, or read by the application. The schema definition may be identical for several consecutive versions, if the interpretation of the same XML has changed, so when in doubt, always increase the version number.
Do what you can educating everyone that they cannot just edit the latest schema and do away with that. Unreliable versioning is worse than no versioning.
Okay SO. I need some guidance. I apologize for the length of this post, but I need to provide some details:
I've got someone who is interested in me to do a small project for them. The application in general is a fairly straightforward employee record keeping / documentation app, but it makes pretty heavy use templated Word and Lotus documents. The idea is you select the employee “event” such as commendation, promotion, discipline, etc., and it loads the appropriate template doc and you fill it in from there, and later you can select an employee, view all the “events,” and view the individual documents associated with each one.
Thus, the app must know where the .docs are saved when the user is done.
The client actually has a v1 of this app (it doesn’t do any management of the files or anything, just launches Word/Lotus with the document you wanted to view in a new instance, presumably via a system() call.) We’ve not gotten into a detailed requirements phase, but the client and I agree that for this to really work, some kind of control over where the user saves the .doc’s to is going to be critical , because otherwise the app provides them with the new copy of the template doc, they "Save as" somewhere else, and the app is pointing to the blank copy it provided them with.
Obviously, I can’t think of a way to achieve “Save as” restriction/control in any way via just launching a new instance of Word. The client has the idea of an embedded Word/Lotus instance in the app with the template doc when you choose one, but I’ve few reservations with that:
I’ve dug around online and I’ve read that whichever version of Word I borrow MSWORD.OLB from will be the one the end user would require?
I’ve tried to do the MSDN example of embedding a Word doc from here, but as I’ve come to get used to, the MSDN example doesn’t even compile.
Even if I CAN figure out how to embed a .doc file into their application, I don’t know that I could control the use of “Save as…”
All of this STILL hasn’t touched on Lotus (!)
So… instinctively, I feel the embedded Word/Lotus thing has to be more work than it’s worth in the end.
So I’ve had a few other ideas brewing around.
One is looking into using Office XML (and if there’s a lotus equivalent), and get the user’s “inputs” separately and generate the document on the fly each time. I’m not particularly thrilled with that idea, but I think it COULD work, provided I just use old features to try and stay far backwards compatible.
Get user’s “inputs” separately and generate a document in HTML. Meh. Works, very cross platform and easily parsed and understood, but not good if you want to be able to email it to someone (who emails a .html? Works, yes, very unconventional which to the average user will throw them off) and even worse if you need to email it to someone for revisions…
Perhaps some kind of editable PDF? I know there are PDF libraries out there, and the more I stew on it, the more this sounds like the best option, though I’ve not done much work with PDFs and I don’t know how easily embeddable they are / what options one has when creating them. I know they can be save-disabled, I’ve had that with my bloody state taxes before.
I need some input here. Here’s the TLDR questions:
Is launching a new instance of Word for each .doc as bad as I feel, given user can “Save as” document wherever and then application is left pointing to a blank document?
Is trying to support embedded Word as big of a trouble as I feel like it is / more work than it’s worth / likely to cause problems with supporting multiple versions of Word? (Forward compatibility as well as currently released versions?)
What are thoughts on the PDF plan?
Any other good ideas?
Word does allow for programming some "Save" and "Save As" control via its object model. Any subroutines coded in VBA and placed into your Word template will be copied into all documents generated from that template. Additionally, most menu and Ribbon commands can be intercepted by creating a module containing subroutines named for the intercepted commands. So, for example, if a module contains a sub named FileSaveAs(), any code in that sub will be executed instead of the standard File|Save As command. Lastly, this code will replace Save As commands executed via keystroke, toolbar, menu, or Ribbon.
The code below will launch a dialog box to a predetermined path whenever a "Save" or "Save As" command is executed:
Sub FileSave()
ControlSaveLocation
End Sub
Sub FileSaveAs()
ControlSaveLocation
End Sub
Sub ControlSaveLocation()
Dim Directory As String
Directory = "C:\Documents\"
With Application.Dialogs(wdDialogFileSaveAs)
.Name = Directory
.Show
End With
End Sub
Hope this helps.
I'm starting some work on an existing ColdFusion application with no version control and what look like unused cfm files (test.cfm, test2.cfm etc.). I'd like to get a picture of what files are actually part of the application so I can get it into git or subversion in a manageable state.
How would you go about this? A regex and some methods to find and map cfinclude and cfcomponent tags? Is there some existing tool that does this?
Ben Nadel has a method to examine the live stack trace from a running template. It seems to me that you could easily plop this into your application and log the results to a database. Once you've done that, you've got a good idea of what's in use and what's not.
I think the easiest way, however, is to enable debugging (standard caveat here about development server, etc). The standard ColdFusion debugger will give you a complete list of every file used during the execution of a single page. ColdFire will do the same thing in a handy Firebug extension (click ColdFusion then click Exec Times).
It should be pointed out that the built-in debugger even shows you the files included from CFC calls, and the files included from within those calls as well. It is all inclusive.
Ben Nadel on Stack Traces
Ray Camden's ColdFire
Sample of CF Debugging from a live page:
Put it into git first! Then, if you screw up, you can easily roll back.
(If you're concerned about having a 'clean' repository, when you're finished and fully tested, you have the option to just remove the single .git folder and create a new one.)
Then, as Tomalak suggests, use cflog on every file. Infact I'd say maybe even log twice, at the top and bottom of each script, could potentially help you to map out how the application runs.
A regex is not advisable. Since ColdFusion is quite flexible in the way files can be included or referenced, there will be no way to determine the definitive list of dependencies from the source code alone.
You could insert a <cflog> into each file and build a log from the running application. Examine the log after the application was active for a while and all functionality had been accessed at least once.
Don't bother instrumenting each file, just cflog the page name in OnRequest inside application.cfc - the target page is an argument.
Of course then the issue becomes code coverage and the ability to fully excercise the app.
<cffunction name="onRequest" returnType="void">
<cfargument name="targetPage" type="String" required=true/>
<cflog file="Usedpage" text="#Arguments.targetPage#">
<cfinclude template="#Arguments.targetPage#">
...
</cffunction>
cfinclude won't tell you if a url is supposed to load the file directly. I've seen system where some files are not included via an index.cfm even when the framework expects it. I have it in my own work where index.cfm loads most code but reset.cfm bypasses the framework to reset configs and session data.
Download a trial of Dreamweaver and define a ColdFusion site. DW can create a site map and tell you which files are not included, linked, cfmoduled and so forth. I don't know if it can figure out unused CFCs, but CFMs should be easy. Note that I haven't used DW for years, but it had this functionality around CF 4/5.