Wrong

G'day:
I was wrong to call-out Rupesh about being dishonest yesterday, in the context of this ticket on the bug tracker: "Closures cannot be declared outside of cfscript". I wrote the the article "ColdFusion Team: further erosion of trust" which expressed my derision at my then perception that Rupesh was acting deceitfully.

Both Rupesh and Peter Boughton have furnished evidence to demonstrate I was mistaken, and given that, my reaction to the situation was poor, and out of line.

Rupesh dug out the issue's audit trail showing it had been marked as "Open / To Fix" for quite some time:

And Peter did what I should have done initially, and dug out the Google cache of the page, the relevant detail of which is:

That demonstrates that on 6 Aug 2015, the ticket was marked "To Fix".

I'm not going to dispute that evidence, but I'm buggered if I understand it. I do not understand how I'd be motivated to chase up a ticket which didn't need chasing?! But it seems I did. And I reacted poorly when this was pointed out to me.

This is not the place for me to comment on why my conclusion about Rupesh's feedback was what it was, I was just out of line to jump on him like that.

In the comments of that first article, Rupesh asked "[...] I expect an unconditional public apology from you on this!", and fair enough.

Rupesh I was clearly wrong in my assessment of your actions and motivations for same. It was very bad form of me to not research the situation (as Peter did) first, and my way of dealing with it was outright wrong.

Rupesh also asked me to take the article down, but I'm not going to do that. I am however going to update it and make it clear that I was wrong, and point readers to this article for clarification. I want it to stand as an indictment of myself, so that people know how I can over react, and do the wrong thing.

I am genuinely completely bemused as to how I misread the status of that ticket, but that doesn't really matter here. I am not particularly enamoured with myself today.

Sigh.

--
Adam

re: "erosion of trust"

G'day:
If you read my blog article this morning "ColdFusion Team: further erosion of trust", you should re-read as I have updated it.

Rupesh maintains - and has offered evidence - that the ticket was reopened ages ago. Here's the audit trail he provided:

The key bit here is the bottom entry which show the ticket being reopened.


On the public-facing UI did not reflect that when I commented yesterday. It's as simple as that.

However Rupesh has provided this evidence, and whilst it doesn't match what I saw, he genuinely seems to be maintaining this is the true status.

So, faced with Rupesh and his log, and me and just my witterings on, you should draw your own conclusions as to what reality is here.

I'm not going to take the previous article down (I mention this solely because he has suggested I should) because I stand by what I say, and it continues to be my interpretation of the situation.

However I am not going to suggest Rupesh is posting that log in anything other than good faith, and this all just makes things seem a bit odd.

I'll leave it to you to decide WTF is going on here. But you should apply Occam's Razor to all this, and - TBH - it falls in favour of Rupesh. I'm not gonna ignore that.

Specifically to Rupesh: if you're not just being dodgy, then I apologise for thinking that you are, and drawing everyone's attention to this. However it would be disingenuous of me to suggest I don't still think you're dodgy. Sorry, but... well... there you go, I'm not going to lie about it.

Righto.

--
Adam

ColdFusion Team: further erosion of trustI'm an arsehole

G'day:

Update 4:

I was completely wrong in what I said in this article, and I am not proud of myself as a result. I am leaving the article here as evidence of what a prick I can be. You should instead read this article: "Wrong".

ColdFusion: another security hole has been patched (CF10 and CF11)

G'day:
Just so yer aware, another update for ColdFusion was released this afternoon (UK time). Apparently there's a security hole in ColdFusion's BlazeDS integration which has been fixed. I don't actually know what CF uses BlazeDS for, I have to admit. I don't even know what BlazeDS even is, now that I come to think of it. [quickly googles...]

BlazeDS is a server-based Java remoting and web messaging technology that allows you to connect to back-end distributed data and push data to Adobe Flex and Adobe Integrated Runtime (AIR) Rich Internet applications (RIA).

So no wonder I didn't know what it was.

Anyway, Anit said on the Slack channel that it will on affect you if yer using BlazeDS, so that's probably not most people.

Update:

Seems I've misinterpreted what Anit said, or something, as Rupesh - who is now on the CFML Slack Channel too - has just clarified with this:

Regarding the blazeds 0-day vulnerability that we patched a day back, It seems like there is an impression that the server is not impacted if you are not using blazeds. Your server is not impacted *only* if you have disabled flash remoting. By default it is enabled and hence your server is impacted.

Please make sure to apply this update

The Adobe blog article about it is here: "ColdFusion 11 Update 6 and ColdFusion 10 Update 17 now available". Make sure to subscribe to the comments on that thread to keep yourself up to date with anything "untoward" in the update process. I've not installed it myself yet. Obviously make sure to test the update in your test lab first. Don't just stick it straight on your live boxes. Also bear in mind that CF updates are cumulative, so as well as this particular fix, it'll include all the other bugfixes too, so there's a lot of moving parts that could cause you grief. Regression test thoroughly.

I guess if you're using CF9 or older you're SooL, I'm afraid.

Update re ColdFusion 9:

Piyush has indicated Adobe do have instructions as to how to patch ColdFusion 9 servers, but instead of just posting them like a responsible vendor would do, one has to email him to get them. Groan. However Dave Epler has documented his steps to patch CF9 on his blog: "Manually Patching ColdFusion 9 with APSB15-21 (CVE-2015-3269)". Dave knows what he's doing, so you'll be safe in his hands. Safer than in Adobe's, it would seem.

That's it.

--
Adam

The Adobe ColdFusion Team are doing a bloody good job at the moment

G'day:
I know I am the first (and loudest, and most repetitive...) to whinge about Adobe's ColdFusion lads (/ladesses), but... fair's fair... there's very bloody little to complain about at the moment.

CFML: Advice for Adobe re Railo

G'day:
I was a bit surprised to read this this morning:

The sole reason for adding this functionality was to make it easy for the frameworks to define the datasources from within the framework without going through the administrator. If one has to go through the administrator to get the encrypted password, that defeats the whole purpose. You can very well keep it defined there. So why define it in the application at all? 
As far as the railo approach is concerned, I don't know the details of their implementation. As Hima said, after putting the encrypted string, your code would not be portable because encryption will be installation specific. In case they are claiming the encrypted string is portable, it would mean that they are encrypting it with a static key same across all installation which is not at all a secure practice.

I dunno if Rupesh was meaning "in general" or just "in the context of this topic".

However, to be clear, the very first thing Adobe engineers - especially senior ones who seem to make decisions - should be familiar with is how Railo does stuff, and what features it has. In the context of this specific issue, as soon as I compared ColdFusion's functionality unfavourably with Railo's equivalent functionality, Rupesh should have spun-up his Railo instance and had a look. That's if he didn't already know about it.

As Adobe was playing catch-up with this feature, all the devs involved in it should have already gone over the feature in Railo and used that as a basis to make the CF implementation at least as good, if not better.

I'd be fine if Rupesh had said "yeah, we looked at that and didn't think it had merit because [reason here]", but it sounds like he didn't even know about it.

It would not surprise me if Rupesh doesn't even have Railo installed.

Adobe have to be all over what Railo is doing. They should be members on their mailing list (not just lurking, but actively discussing stuff), they should be checking out all the new features (and bugs!) as soon as they come in, and in general know exactly what the opposition is doing. Not least of all because they could learn a thing or two from Railo's implementation of things.

Obviously it cuts both ways, but I already know the Railo bods are fairly familiar with how ColdFusion operates.

When I read stuff like this, the silo of naïveté that the Adobe team resides in that I have a mental image of gets slightly higher, and the walls slightly thicker.

--
Adam

CFML: Adobe agree to revise their stand on prefixing of list-oriented member functions

G'day:
Just very quickly... you know I wrote an article the other day, "ColdFusion 11: if Adobe haven't quite sapped yer will to live yet..."? Well we got some input from community members other than just myself, and the resounding feedback was "prefix the list member functons with list".

And Rupesh posted this response today:

all right. marking it as ToFix and we will include it in the first update.
In case one has used these list methods, he/she would need to change the code.

Nice one. I guess that's two beers I owe Rupesh now. Cheers fella.

And... go the community input! See it does help if you let Adobe know what you think, rather than just sit there silently gritting yer teeth. So if you find a bug: raise it. If you think it's worth people knowing about, or if you need support making your case: let us know so we can pitch in too.

Anyway, cheers everyone involved in this: good work.

--
Adam

Looping in CFML: community input solicited

G'day:

Yesterday I wrote-up my experiences with the new cfloop() construct in ColdFusion 11: "ColdFusion 11: cfloop in CFScript very broken". The same construct exists in Railo, btw (it's nowhere near as broken).

I raised a ticket with Adobe summarising my findings: 3754577. Overnight Rupesh has come back to me, with this comment:

Though we have added a generic approach for the script syntax for all tags, it does not work in cfloop's case as the tag implementation is directly in the generated code. the exception being query or file and that is why looping over a query or file works but others don't.
Though it would be ideal to do this for completeness, is this really required? We already have cfloop equivalent in cfscript - using "for", "for-in" and "while" loops. file is the only thing that is not supported by "for" or "for-in". I feel we should stick to the "for", "for-in" & "while" and throw a good error for cfloop with indexed, array, list, collection and condition. Thoughts?

It's great to get decent, thoughtful, feedback. I put my own thoughts down in response:

I'm split on this on.

On one hand if you're gonna do this porting of tags to CFScript with this generic approach rather than with a situation-specific one, then I think the approach should be all-encompassing. If it's generic don't second-guess stuff, just do it.

On the other hand, I think perhaps having implemented cfloop() at all was perhaps a bad move. Instead it would have been better to augment the existing CFScript looping construct: for(). There's no reason why that could not have accommodated query- and file-looping functionality. The benefit of this is that for() is a familiar construct for everyone, and it doesn't necessitate yet another looping construct.

What you've ended up with is - same as with the list member functions - a situation where the language isn't "hackable". One cannot simply infer how the looping works from the behaviour of existing constructs. There is no rhyme or reason why one would use for() for arrays, but cfloop() for queries. It makes no sense. One needs to know the inner workings of what the CF Team decided to know how things work, which I think is fairly opaque language design.
I am going to solicit more community input on this, to see what people think.

I decided not to add it to my comment on the bug tracker, but I'll add it here. I also think too often the Adobe team opt for "what's quickest/easiest" rather than "what's best". And I really think this needs to stop. The language needs to come first, then how much effort is involved comes secondary to that. It would be better to not do it at all, rather than to an incomplete job due to timesaving.

A case in point is this looping thing. In CFScript we now have:

• for() - indexed, array, collection
• while() / do() - conditional
• cfloop() - files, queries
• listEach() - lists
• type-specific iteration functions

(I separate those last two out as there's no "procedural" way of looping over a list in CFScript, I think; one needs to use the functional way).

Adding in yet another way of doing looping just to cover files and queries seems wrong to me. They should have either just added in the appropriate iteration functions, or added functionality to for() to handle it. Or both. Both would have been the better solution. But cfloop() is just PHPifying to me.

But, anyway, it's not all down to just what I think (and I wouldn't even want that to be the case). I was hoping you people could pitch in on the conversation too. Care to add your comments onto that ticket I linked to above?

Cheers.

--
Adam

ColdFusion: Credit where it's due: cheers Rupesh

G'day:
I'm pretty hard on Rupesh at times (where those times are "most of them"), but I've just being doing some back-and-forth with him on the bug tracker regarding some bugs / enhancements I'd raised in the past. And it's all been pretty positive.

I'd raised one about first-class functions a week or so ago (so way too late for anything to be done about it in ColdFusion 11): "Built-in functions as "first class" glitch in function expressions", and he's been investigating what's up, and gave me some more repro information; and I've updated with a better repro case as I was wrong about what I thought the issue was before.

Quite a while back I asked for <cfloop> to be deprecated (yes, really; but only in a certain regard): "Deprecate CFLOOP/array and try again", and I never expected any movement on that, but he's suggested a good resolution which doesn't require any deprecation nor would it cause any backwards compat issues.

When I was looking at other languages, a while ago (Ruby, PHP), I had a look at what other interesting operators these and other languages had, and suggested <=> for CFML: "<=>: compare operator"; they might take this up in the next release.

And I had previously suggested combining all the array-finding functions into a single function, and deprecating the existing ones: "arraySearch()". he's been giving that some thought too; basically agreeing, but being uncertain about my suggestion of deprecating the existing ones.

A few other ones I've raising in the past have simply been marked "to fix" without any further commentary:

• replaceWithCallback()
• ==~: regex compare operator
• Arbitrary restriction on IMPORT
• Another suggested tweak to CFScript: thread

Not only am I pleased here because the feedback has gone the way I wanted it to; I'm just pleased there's feedback and a sense of consideration going on here at all. I'm completely OK with any bug / enhancement request I raise being rejected provided there's sounds, transparent reasoning behind it (I don't even need to agree with it; I get that opinions differ)... it's the sense of collaboration and inclusiveness that's important. Of course it's even better still when the ticket gets marked "to fix".

Thanks for the good work Rupesh. Rakshith: buy that man a beer.

--
Adam

ColdFusion 11: if Adobe haven't quite sapped yer will to live yet...

... could you do me a quick favour?

G'day:
A while back I raised this ticket with Adobe: 'List member functions should all be prefixed with "list"'; it's kinda self explanatory, but the gist is they'd implemented list member functions (good), but changed the names of the member functions to no-longer match their headless function counterparts. So the member function version of listAppend() was just append(); listEach() was just each().

I figured this was of dubious merit as it muddied what was a list-oriented member function and what was simply a string-oriented one (.append() could just as easily do a string-append as opposed to a list-append), and this notion got a lot of support: "Survey results: lists in CFML, and the naming of list member functions".

Credit where it's due, Adobe marked it to fix, and indeed "fixed" it before release of ColdFusion 11. So now we have myList.listAppend(), myList.listFind(), etc. But we still have myList.changeDelims(), myList.each() and a few others haven't got their list prefixes.

I duly raised another bug to cover this, yesterday: "listChangeDelims() member function missing".

Today Rupesh simply closed this ticket as "Closed/Withdrawn/NotABug", offering this insight:

delimiter is meaningful only for list and therefore there is no ambiguity on this. That is the reason the list methods dont need any separate qualification.
list.changeDelims() is better than list.listChangeDelims()
Same is the case for map, each and filter methods. They apply only for collection and I don't see any ambiguity there.

Honestly? Sigh.

ColdFusion: Of integers and indolence

G'day:

Yes, OK, I'm still banging on about integers and ColdFusion bugs. It's my blog and I can talk about whatever I like! ;-)

You might be aware that I am particularly nonplussed about Adobe's reaction to bug 3712010, which relates to integer validation via isValid(), and how it is broken.

I started by just being mildly annoyed by how ColdFusion can make such a pig's ear of something that should be simply. But the more Adobe (or, hey, let's say it: Rupesh from Adobe) squirms about the place and tries to justify why they shouldn't just bloody fix a fairly obvious bug, the more annoyed I am getting about this. I dislike having my intelligence insulted, and I also dislike the collective intelligence of the ColdFusion community insulted. Especially by someone who very clearly should not be in the business of insulting anyone's intelligence.

It's all getting a bit stupid, but one of the comments posted today on this caught my eye and made my blood boil just that bit more. I've asked Carl if I can reproduce his comment, and he has said it's fine. So here it is. I've dollied it up for formatting, but it's othewise unchanged.

ColdFusion: Fixing any bug has backwards compatibility concerns

G'day:
I'm going to bang on about isValid() and integers some more. You've been warned.

Right, so I was horrified to see that this is the case in ColdFusion:

isValid("integer", "$,1,2,$,2352345,$"): YES

And, what's more, having used ColdFusion to establish that $,1,2,$,2352345,$ is in fact an integer, if I then try to use it as an integer, ColdFusion breaks. At least it gets this half right. I discuss this at undue length in "Can we please agree that Adobe is not the arbitor of what constitutes an integer?".

Good old Rupesh poked his head above the parapet briefly, and offered a better response than one might expect here:

Rupesh Kumar • a day ago

There is no doubt that this behavior is incorrect. It is obviously wrong and it should be corrected. However, it has been like this forever and making such a fundamental change has a great potential to break a lot of applications. We dont want to do that in this release. As Rakshith has already communicated, we plan to take up such changes in 'Dazzle' where we will correct the behavior without worrying about backward compatibility.

This is an improvement over his earlier comment on the topic:

• 
  Rupesh Kumar

  2:53:06 AM GMT+00:00 Apr 24, 2012

  This has always been the behavior and changing this would result in backward compatibility issue. It will not be fixed.

There's a fundamental error in Rupesh's internal logic here. To suggest that fixing a bug somehow has backwards compatibility issues is utterly specious.

Intrinsically "a bug" causes some manner of behaviour to occur. It's a bug because the behaviour is incorrect. And, intrinsically, if a bug is fixed, it is implicit that the previous behaviour will change. That's the entire reason for fixing the bug: to replace incorrect behaviour with correct behaviour. So, on the face of it (and this is why I say his position is specious, not simply out and out frickin' stupid... although it is also that), this creates a backwards compatibility consideration. Because the new (correct) behaviour will be different from old (incorrect) behaviour.

But this is the nature of fixing bugs. The behaviour of the buggy functionality changes because it becomes "not buggy". If we were to clamour "backwards compatibility!" each time we considered fixing a bug... no bugs could ever possibly be fixed. And clearly we do fix bugs (obviously). So "backwards compatibility" is not grounds for not fixing bugs. Because it is not actually a valid consideration.

ColdFusion: Participate in your community

G'day:
One of the things a lot of the ColdFusion community members could do to improve things is... lift their game when it comes to being part of the community!

There's been a coupla examples over the last few days of this sort of thing:

Bug 3678476

Title
Few Image functions are not shown in the Coldfusion image functions list

Description
http://help.adobe.com/en_US/ColdFusion/10.0/Developing/WSc3ff6d0ea77859461172e0811cbec12207-7ffd.html#WSc3ff6d0ea77859461172e0811cbec12207-7ffa

This URL should contain the below image function:
ImageGetIPTCMetaData
ImageGetEXIFMetaData

Rupesh commenting against bug 3678093:

cfloop does have a charset attribute which is used for reading the file. however this is missing from the documentation. This needs to be documented.

(my emphasis)

From Twitter:

Come on adobe. Your #coldfusion documentation sucks. The code examples for cfcontinue on both cf9 and 10 don't even use it!
— Steven Neiland (@sneiland) January 6, 2014

(and even once I fixed this one, conversation continued as to how (not) good my fix actually was!)

But in all three examples the person writing is correct.

And all three examples are now fixed. Why? Because I just went in and bloody fixed them.

Help me understand how a CFML REST request should not cause onCfcRequest() to fire

G'day:
I have to admit I am not very au fait with the idiosyncrasies of REST requests. To me a REST request is just... a request. The difference being the mechanism at the other end is more likely to respect verbs other than GET and POST like normal browser-based requests make, and they return "data" rather than mark-up. But other than that: there's nothing really to them. It's more a concept / strategy than anything else.

In this light, a while back I noticed that a REST request I was making didn't fire the associated onCfcRequest() event handler, as documented here: "REST requests don't seem to correctly use Application.cfc either". I duly raised a ticket: 3590745.

Rupesh has come back with this:

OnCFCRequest is meant for the requests which are made directly to the CFC - as AJAX request or directly over HTTP. For Rest request or web service or web socket requests, CFC happens to be an end point to a request (where the CFC is not explicitly invoked) and therefore OnCFCRequest is not called for these three types of requests.

I understand what he's saying, but to me - as I say in my follow-up - what he says seems like an example of post hoc ergo propter hoc. Basically the conclusion drawn is not implied by the supporting information. Here's what I said in response:

ColdFusion: contempt of court

G'day:
Be forewarned. If you're the sort of person who reacts poorly to me being a meany, then can I just refer to this this right now: "Why weI fight" (and this blog's communication policy), and perhaps you oughtn't bother reading this. I do call into question someone in our community's professional capabilities here. And some of you might not like that. [shrug].

I am reproducing this here, as some of it has already been redacted by Adobe. I understand why they have done this: fair enough.

Here's an exchange in the comments (OK, not the best place for me to have posted some of this, I know) against bug 3648781: "Closures cannot be declared outside of cfscript".


Rupesh Kumar (RK):

11:02:55 PM GMT+00:00 Jan 1, 2014

It is not about half implementation at all. Outside cfscript, functions are declared using cffunction tag. Now how do you define the closures in tag syntax? The only way to do that would be using an ugly mix of script and tag which would look like

<cfset c = function(){
    var a = something;
    var b = foo();
    return a * b;
}>

To me, this syntax looks confusing. Given that more and more new code is being written in cfscript, I feel we should not mix script and tags in this way. Deferring it for the time being and we will revisit this later.

Adam Cameron (AC):

3:01:16 AM GMT+00:00 Jan 2, 2014

It's just an expression like any other sort of expression, Rupesh.

You can't say "oh, this sort of expression is OK in a CFSET statement, but this other sort of expression? No, can't do one of those". That's ridiculous.

By way of comparison, this already works fine in Railo. But then again they're not quite so judgemental/patronising as to what will / won't look "too complicated" for CFML developers.

I think if it looks complicated *to you*, you probably should not be making decisions as to what does and does not go into the language.

--
Adam

ColdFusion: Latest from Adobe on the getParameter() thing

G'day:
Just noticed this new comment on 3222889:

Of course the method is there since it is part of the interface. It is just that the call for getParameter('param') is returning null and we will have to debug Tomcat source to understand that. This object is coming from Tomcat and we don't have any control on it and hence we can't do much about it.
However, I am curious to know the scenarios when you would like to use it. We anyway provide you the Form scope through which you would get all the request parameters. What would be the scenario when you would not want to use the Form scope and use the getParameter method of the request object?
We exposed the API to get the underlying application server's pageContext object and we are giving that. But if some method on that object is not working correctly, it would certainly be not a bug with ColdFusion, would it? 

This kinda conflicts with Micha's findings about the same, doesn't it?

I'd also like to point out that this has already been explained in comments against the ticket. However it would of course require Rupesh to pay attention to them.

But fair's fair: there's not a huge amount of detail from Damon there. I will touch base with him and see if I can get a better understanding of what's going on, and why he needs this, and replicate it here.

And now I have a day job to attend to.

--
Adam

Things I dislike: jobsworths

G'day:

Update:
For non-UK-English-speakers, from Wikipedia:

A jobsworth is a person who uses their job description in a deliberately uncooperative way, or who seemingly delights in acting in an obstructive or unhelpful manner.

I started to have a quick look at ColdFusion 10's new ESAPI functions this morning...  I'd give you a link for those, but they don't seem to be categorised in the docs (and I can't annotate the docs accordingly, cos the site is still broken since it was "upgraded" to use the new wiki)... and quickly got deviated onto the bug tracker.

ColdFusion: Good communications from Adobe

G'day:
I'm always quick to berate Adobe for poor communications, so - fair's fair - here's a "hey nice one!" at them - Rupesh in particular - for some feedback he's given on one of the tickets I had raised on the bug base.

Ages ago I found that there was no native way in CFML to determine if a variable is a file handle. EG: we've got isStruct(), isArray() etc, but no isFile() or similar. I wrote an article about this: "How do I know if this variable is a file handle?" I also raised an enhancement request (3299625) to get it dealt with.


Pleasingly it's been marked as "fixed", so in ColdFusion 11 we'll have isFileObject() (which I think is a better name than my suggested isFile()). The reason I know this detail of what the function will be is because Rupesh has taken the time to feed back on the ticket. This is cool. It might seem trivial, but this sort of community engagement is really good, and makes Adobe look far less faceless than they come across sometimes.

So cheers for the feedback Rupesh. And keep it up!

--
Adam