Showing posts with label ColdFusion 11. Show all posts
Showing posts with label ColdFusion 11. Show all posts

Sunday 27 April 2014

ColdFusion 11: <cfclient> seems to require /CFIDE to be available

G'day:
This will be a short one... I just want to trot out various observations I make about <cfclient> as I make them. I don't want to waste too much effort on it.

I also feel a bit dirty round about now... I'm about to use a <cfform> tag.

As should everyone, I do not expose /CFIDE to the outside world. This is a terrible vector for security vulnerabilities. One that Adobe seems to be dragging its heels about resolving once and for all ("Isolate the /CFIDE/scripts directory from the rest of /CFIDE" (3732913)).

So when I'm using <cfform> (which is only ever when I am writing example code like this), I need to redirect ColdFusion to look in my isolated directory which just has the script stuff in it:

Saturday 26 April 2014

ColdFusion 11: <cfclient> in the context of the CFML language, not the tooling

G'day:
This article could end up being a complete waste of space, as I am operating under more real-world re-interpretation of the raison d'ĂȘtre of <cfclient>, as described by Ram:
ColdFusion [11] has added support for client side CFML (<cfclient>) and this code is translated to JavaScript
Mike Henke has pointed out that the first part of this "CF11 has added support for client-side CFML" is actually bullshit (my wording, not his):
"ColdFusion Splendor has added support for client side CFML" is probably phrased wrong and gave me flash backs to VBScript or CFML running in the client browser.
Maybe this is better verbiage. "ColdFusion Splendor has added support for CFML to generate JS".
Because... there's not such thing as "client-side CFML". That would imply CFML actually running on the client (ie: the browser, or the mobile device, as is the target of <cfclient> as a concept). This is absolutely not true. I know Ram went on to qualify what he meant there, but the messaging from Adobe on <cfclient> has been inaccurate. Possibly I think to the point of actual misrepresentation (in the legal sense, I mean).

What <cfclient> does is... convert CFML code to JavaScript. So let's look at that idea.

Friday 25 April 2014

ColdFusion 11: custom serialisers. More questions than answers

G'day:
I've been wanting to write an article about the new custom serialiser one can have in ColdFusion 11, but having looked at it I have more questions than I have answers, so I have put it off. But, equally, I have no place to ask the questions, so I'm stymied. So I figured I'd write an article covering my initial questions. Maybe someone can answer then.

Tuesday 22 April 2014

ColdFusion 11: quick look at what data-type built-in functions are, in the context of using them as first-class functions

G'day:
That was a foolishly long title. Oh well. The article itself is gonna be a quicky as I haven't had dinner yet and I'm getting hungry. Once I've cooked and got wine in hand... I'm not gonna be interest in writing this up.

Awdhesh and Rakshith gave an online presentation today on some of the language features of ColdFusion 11, and the subject of built-in functions being elevated to first class status came up. I thought I had covered this, but I'm buggered if I can find the article. If this is a double-up: sorry.

Saturday 12 April 2014

ColdFusion 11 is not ready for release in one month's time. Simple.

G'day:
This is a short adjunct, designed to encourage the Adobe ColdFusion Team to respond to their community. It'd be helpful if you could retweet it.

In my opinion, CF11 is not ready to release for one very good reason:

67 ColdFusion  bugs not even looked at yet? Yer having a fucking laugh, Rakshith.

I wrote a speculative article the other day: "ColdFusion 11 release date confirmed to be no later than...", which intuits that we're about four weeks shy of ColdFusion 11 coming out. I think this is borne out by an increase of bug closures with "can't be arsed... maybe in two years time" (I think it actually said "Closed/EnchancementRequired" or "Closed/NotEnoughTime").

However as far as I can tell, Adobe haven't even bothered to look at a whole bunch of the issues their paying customers have raised with them.

I really don't understand how Adobe can be so dismissive of their clients. I seriously can't see how this is even "minimum professional" behaviour, let alone appropriate behaviour when they're in one of their very rare development cycles.

In contrast, Railo has the "luxury" of being able to do continuous development, so continuous issue triage/resolution, and they very rarely leave an issue untriaged (and even unfixed!).

Adobe choose to only do development on ColdFusion once in a blue moon, so they really have to at least triage all the currently outstanding issues. And, if they were to have any sense of professional integrity, fix the bugs, implement the features, or explain why they don't.

Adobe have done a bunch of good stuff for ColdFusion 11, but they are way more than a month away from delivering a professional product. Part of being professional is listening to one's clients.

I would like Rakshith to respond to this article. And what's up with their bug-fixing...

--
Adam

Bugs in iterator functions in both Railo and ColdFusion

G'day:
I decided to "do my bit" for the cfbackport project, and am looking at implementing the new collection iteration functions for older versions of ColdFusion. I'm aiming for CMFX6.0 onwards, but am having to guess at some of the language restrictions as I'm on my back-up laptop and only have CF10 & 11 to test with.

Thursday 10 April 2014

ColdFusion 11 release date confirmed to be no later than...

G'day:
This is the first "official" statement from Adobe I've heard about ColdFusion 11's release date. I was watching Ray's presentation that he gave to the Salt Lake City UG: "Recording and demos from my ColdFusion 11 presentation", and he let a tentative timeframe slip...

Wednesday 9 April 2014

Ye Olde XMLSearche Bugge

G'day:
Henry mentioned this last night:

That sounded like something I could get my teeth into, so had a look at it this morning.

Saturday 5 April 2014

Closed:Deferred:EnhancementRequired:CantBeArsed:Adobe:ColdFusion

G'day:
Very disappointing action from Adobe today, regarding securing /CFIDE. Adobe have followed-up the ticket I discuss in "Encourage Adobe to relocate /CFIDE/scripts", 3732913:



And they've done this without any hint of an explanation - you know, having the professionalism (even the civility) to pop an explanatory comment in on the ticket.

So it all sounds like they just couldn't be arsed. I mean... "enhancement required"? Basically they're actually saying "we won't do this because it would require us doing some work". Heaven forbid.

Slack.

--
Adam

Thursday 3 April 2014

Wednesday 2 April 2014

Survey results: lists in CFML, and the naming of list member functions

G'day:
I didn't quite get 50 results for this survey, but so be it. It wasn't a terribly interesting one, granted. So, what do people think about lists, list functions, and what the approach to the naming of list member functions should be?

The subject line of the survey was:
ColdFusion 11 and Railo 4 have added "member functions" to CFML, so one can call a method on an object, rather than pass an object to a function. ColdFusion has implemented list functions as member functions of a string, and in the process have blurred the distinction between what's a list function and what's a string function. There is conversation about this on the Railo Google Group, and this has lead me to wonder what the community participants think about Adobe's approach here.
There were five questions.

Sunday 30 March 2014

ColdFusion 11: calling a stored procedure from script. And can we please stop wearing out our "c" and "f" keys?

G'day:
I'm not sure what's got into me today... I'm supposed to be completing a Backbone.js course @ Code School, but I keep finding things to look at in Railo / ColdFusion instead. This is the fourth article I've written this afternoon. And it's only 3pm.

I'm looking at two things in this article. Calling a stored procedure from CFScript, and how I really don't think our code needs to scream "cf" "cf" "cf" at us the whole time. We get it. It's a CFM file. It's got CFML in it. We don't also need every single line of code in it reminding us of this. But this is what we will have if Adobe get their way.

Friday 28 March 2014

Survey: lists in CFML, and the naming of list member functions

G'day:
There's a conversation brewing on the Railo Google Group regarding string / list member functions ("String member functions and list functions"), and this touches on ColdFusion's approach to these.

TL;DR: the survey is here: "List function support as member functions in CFML"

Update:

The survey is now closed. Results are here.


The question being asked on the Railo forum is whether to bother supporting list member functions in Railo at all. And as an aside to this, some lack of uniformity in how ColdFusion 11 has implemented these has cropped-up.

Firstly, I'll "go on record" as saying that I think having a specific concept as a "list" as a (pseudo) data type in CFML is a bit rubbish. Strings aren't intended for implementing data collections, and aren't very good at doing it, so - IMO - it was a poor idea to facilitate it. If Railo and ColdFusion deprecated the concept of lists entirely, the (CFML) world would be a better place.

That said, they are in the language as a concept, so we have to acknowledge this I guess.

Adobe have added list member functions to CFML in ColdFusion 11.  Here's a table of their implementation ("Supported List member functions"):

Wednesday 19 March 2014

ColdFusion 11: bug triage (and fixing?) seems to have stalled

G'day:
Ages back I wrote an article "212 untriaged ColdFusion 10 bugs", and indicated my horror at how many bugs in the current version of ColdFusion that Adobe had seen fit to simply ignore. I don't mean "not fix", I meant "just completely ignore; ie: not even acknowledge the bug had been raised".

I followed this up a coupla months later with "Bug watch: 212206 untriaged ColdFusion 10 bugs"; in that two months they had managed to triage a net of six tickets that had been raised.

Just a week later we were down to 165 untriaged bugs: "Good work Adobe ColdFusion Team!", and they had made good progress from there, getting it well below 100 untriaged bugs, and got it down to a low of 40 on Jan 22 this year. Again: good work!

Friday 14 March 2014

ColdFusion 11: More on this <cfinclude> thing

G'day:
I've been thinking about this new <cfinclude> security feature some more, based in no small part on the excellent reader comments on my earlier article "Is Adobe knowingly leaving exploits in ColdFusion 9 and 10 unpatched?".

Firstly I'll repeat my response to one of Sean's comments, to contextualise a baseline:

If there's a case to address, and this is a sensible way of dealing with it: no problem. However we didn't know (beyond speculation) whether either of those is true. Rupesh has now clarified there is a case to address, but I remain skeptical as to whether this is at all a sensible approach.

It comes down to communication, and Adobe's seeming inability to do it coherently. On the face of it this was just a stupid thing to do, especially when the rationale was no more developed than "because security". Part of dealing with security responsibly is to communicate the situation. Not to detail the instructions of how to implement the exploit, but at least documenting what the issue is actually addressing. Even had Adobe implemented a more even-handed solution from the outset, without explaining the situation, the community cannot make an informed decision as to whether it's a ill-conceived annoyance that might as well be disabled, or the most critical and real threat ever. I still think this one falls closer to the former than the latter.

Furthermore, without discussion and input from the community, I will never be certain (nor should any of us be) that Adobe are actually addressing the issue sensibly, or just giving it a quick hack by way of lip-service. Let's face it: they do have a habit of doing the bare-minimum amount of work necessary to be able to look themselves in the mirror (although they set a low tide mark even for that).

And also - finally - a helpful comment from Adobe's technical mouthpiece, Rupesh:

Rupesh Kumar
6:51:43AM GMT+00:00 Mar 13, 2014
As I said earlier, this basically provides a way to you to decide what you want to compile and what not, when the file is being included. This was added after we saw few cases where an application included a file and somehow the bad guys were able to write to this file being included. The file in one of the case was actually a log file where the application was logging invalid user input apart from other errors/log messages. As you would figure, the bad input was actually some CFM code which went into the log file and when this got included, the user given code got executed. The application had not expected this file to be compiled. As we understand, there are many applications which use cfinclude to include static content.

This is a good change. You are getting a control to decide what to compile. You will also get some performance improvement because your JS, HTM, CSS files would not be compiled, loaded and processed by the server. If you don't need any of this and want to compile everything, you can always use "wildcard". 

To answer whether this should be given as an update to CF 9 & 10, we would not want to break applications while applying updates in their production servers. We can add this where by default we would allow all the extensions to be compiled which then does not fix anything immediately. So how do we go about it? Do you think it needs to be made available in CF 9 & CF 10?
There are some comments following that up, and you should read them.

Wednesday 12 March 2014

ColdFusion 11: good news... <cfhtmltopdf> will be able to run on Linux too!

G'day:
Just a short one... I figured it would be good if someone publicises this fact a bit more:


ColdFusion 11: Confusion as to why <cfhtmltopdf> is not simply an adjunct to <cfdocument>

G'day:
I had a look at <cfhtmltopdf> a week or so ago in "ColdFusion 11: <cfhtmltopdf> is pretty good!". And as I say in the article title: it works really well (other than a coupla bugs I raised). However one thing I can't work out is why we now have two tags that do the same thing: <cfdocument> and <cfhtmltopdf>.

They might - under the hood - use different mechanisms to arrive at the same goal, but surely the whole thing about having a tab abstraction layer is that the underlying mechanism ought to be irrelevant: the tags - and indeed the CFML language as a whole - is supposed to abstract the minutiae away from the developer.

A coupla things that are different about <cfhtmltopdf> are:
  1. it only works on Windows;
  2. it is enterprise only.
Both of these are a bit shitty (or a lot shitty, really), but they do not - in my mind - justify why <cfhtmltopdf> is a separate tag.

So, anyway, I asked on Twitter for some sort of explanation:

And this morning I got a response from Rakshith (well I am presuming he's still the man behind the curtain of the @ColdFusion account?)

Sunday 9 March 2014

Is Adobe knowingly leaving exploits in ColdFusion 9 and 10 unpatched?

G'day:
I am very very much leveraging Betteridge's Law of headlines in my article headline above. The answer is - almost certainly - no. However it's perhaps a question that needs to be asked, if some conclusions I'm reading on Twitter today are to be taken seriously.

I'm trying to get some clarification on this security situation in which is "dealt with" by this addition of the allowedextforinclude (note: this was changed to compileextforinclude, by the time ColdFusion 11 was actually released) setting in neo-runtime.xml (discussed in this article: "ColdFusion 11: preventing files from being included? WTF, Adobe?"). There's a ticket in the bugbase "Either remove allowedextforinclude functionality entirely, or at least implement it so it can be disabled". The agreed-to fix here is as follows:

  • S V Pavankumar
    5:46:57 AM GMT+00:00 Feb 27, 2014
    Added the new change. 

    The new behavior will be
    1) By default only cfm files gets compiled in cfinclude tag and all other file types gets included statically. 
    2) The key allowedextforinclude now can be specified at the application as well. 
    3) Added the setting to Server settings -> settings page 
    4) If wildcard(*) is specified in the value all files will be compiled. Wildcard support is added at both server and application level.

OK, so it seems it's completely OK to disable this thing.

Wednesday 5 March 2014

ColdFusion 11: Thank-you Carl, Mary-Jo, many other community members and indeed Rupesh

G'day:
Integers. We "won". Adobe have reversed their position, and they're gonna fix the isValid("integer") bug:

  • Rupesh Kumar
    9:18:35 PM GMT+00:00 Mar 4, 2014
    Wow - it is indeed incredible. Thanks Carl for digging this out. We will fix it - we would have a application setting which would bring back the old behavior in case some one needs it. I hope nobody needs to use this flag. 

    We will also roll it out in an update for the public beta and we would need your help in verifying and making sure that applications don't break. 

    Thank you everyone for raising this and providing this feedback!

Good stuff, Rupesh.

--
Adam

Sunday 2 March 2014

ColdFusion 11: Adobe have finally started deprecating / obsoleting stuff in ColdFusion

G'day:
This article is basically gonna be a reproduction of something in the ColdFusion 11 docs, just FYI. I found an xls file buried in the docs that lists some stuff that's newly deprecated in CF11, and even some stuff they've finally obsoleted.