Coder's Revolution

Do you want a revolution?

Category Filtering: 'CF'

How CommandBox Has Changed The Way I Help People On The ColdBox List

ColdBox, ColdFusion, CommandBox

I spend a lot of time answering questions on the ColdBox Google Group.  Perhaps too much time, since it's all volunteer, but alas I enjoy helping people.  Often times people can't get something working in their site like they want.  It may involve optional ColdBox libraries, specific handler setups, or modules.  The best way to help them is to actually create  their setup locally on my PC and try it out.  Of course, this can be a prohibitively time-consuming process just to answer a question.  

Boilerplate Drudgery 

I do most of my development on Railo, and setting up a new site consisted roughly of the following:

  1. Add hostname to hosts file tat resolves to localhost like myProject.dev
  2. Create a folder somewhere on my hard drive to host the root of the site
  3. Add new context to Railo's server.xml using the same hostname and web root
  4. Add site to Apache w/permissions and reverse proxy and rewrites
  5. Restart Railo and Apache

Now, if this was a ColdBox site, I would also need to:

  1. Visit the coldbox.org download page
  2. Download the necessary version of ColdBox
  3. Unzip it into the web root
  4. Grab an application template, or use the ColdBox platform utilities in CFBuilder IF I have a project set up for this site.

Wow, NOW I'm ready to start replicating the user's issues.  That's a lot of work for a one-time site I'm going to delete in 20 minutes.  Now, what happens when I want to tell the other user how to set up the same site to test on their end?  I think you get the picture.  To be honest, I usually didn't bother and would just throw out a guess as to what the user's issue was.

Work Smarter, Not Harder

Enter CommandBox.  This is a CLI, Package Manager, and REPL and comes with an embedded server and a growing list of generator commands.  This means I  can open up a console and in a few SECONDS have a brand new site created in a folder of my choice with ColdBox installed, an application template generated, modules or handlers installed, you name it.  And then I just type "start".  That's it.  About 3 seconds later a browser window opens and I'm using my new test ColdBox app.  

Let's take a look at the commands I used earlier today to test URL routing to two different handlers with the same name in different subdirectories.  

mkdir myTestSite
cd myTestSite
coldbox create app myApp --installColdBox
coldbox create handler event userlists
coldbox create handler pdt\real\ldr\ldr_nm\ldr_portal\ldr_agt\event userlists
start --!openBrowser --force
server open URI="/index.cfm?event\=event.userlists"
server open URI="/index.cfm?event\=pdt.real.ldr.ldr_nm.ldr_portal.ldr_agt.event.userLists"

That created an app that exactly matched what the original poster had reported and even opened up the test URLs after starting the server.  What's even better is I actually threw those commands in a recipe file called makeSite.boxr so I could tweak the recipe and run it repeatedly like this:

recipe makeSite.boxr

This is the beauty of making something automatable!  Then, I pasted those commands back into the mailing list so the user could try the same thing I did.  And when I was done, I just stopped the server with the "stop" command and removed the directory.  It's like it was never there.

CommandBox has changed the way I develop.  Admittedly more than I ever thought it would.  Spinning up test sites, installing/uninstalling modules, or even trying out a few lines of ad-hoc code with the REPL is so easy now.  I even use CommandBox for my client work too.  I can start up multiple dedicated servers based on what I'm working on that day, and just stop them when I'm through.

3

CommandBox Presentation Recording And Slides For NECFUG

CFSummit, ColdBox, ColdFusion, Presentations

I was honored to be able to present on one of my newly-favorite topics tonight to the Nebraska CF User Group: CommandBox CLI, REPL, and Package Manager.  CommandBox is a brand new tool and unequaled in the CFML world.  It has the potential to really bring CFML devs up to speed with the kinds of tooling and automation that other platforms enjoy if people really embrace it and help build the community it needs to thrive.  

I had a wonderful time showing off cool features and answering great questions with the group and others who joined online.  I've also had this topic selected to present at CF Summit this year so I'm soliciting feedback (good or bad) on the slides, demos, or presentation style to help me tighten up my talk some more before CF Summit.

Recording URL 1hr 30min:

http://experts.adobeconnect.com/p8q3zuxan1j/

Slide Deck:

CommandBox - Brad Wood.pdf

Links from the presentation:

 

0

I'm Going Commando at CFSummit! (With CommandBox)

ColdFusion

 

 

 

I'm very honored to announce that my topic "Go Commando, with CommandBox! CLI + REPL + Package Manager for CFML" has been selected for this year's ColdFusion Summit  Last year's inaugural event was a big success in my opinion and filled with great people and great topics.

 CommandBox is a new command line tool for ColdFusion developers that allows for all kinds of cool automation and package management.  It's the first of its kind in the CFML space and I'm actually writing it as we speak!  The link above has a sneak peek video of some of its features and by the time CFSummit rolls around I'll have even more cool stuff to show like dependency management and task runners.  Here's the topic description:

Go Commando, with CommandBox! CLI + REPL + Package Manager for CFML

A software craftsman is only as good as his or her tools, and quite frankly-- most CF developers' tools suck. For years CFML developers have relied on IDEs and text editors for their work, but what about when they wanted to spin up another server, install a library, scaffold out another site, perform a repetitive task, or just try out a snippet of code? The answer is that they did it manually. And what if they needed to do it again the next day? It was the same old story! Even though CFML as a language has modernized over the years, other platforms have advanced in the arena of developer tools while many of us still sit at work all day staring at the same glorified text editor. If you've only ever used CF, you probably don't even realize what you're missing, and it falls in 3 main categories:

  • Power and expressiveness of tools
  • Sharing and acquiring code with the community
  • Productivity through automation

A GUI may provide the lowest entry barrier and initial intuitiveness, but it always comes with limits and restrictions to what you can do, and how easily/quickly you can do it. A Command Line Interface (CLI) is a common paradigm with a simple interface that can support any number of commands for all the common tasks you perform on a daily basis like creating new bits for your application, running tests, installing 3rd party libraries or starting a server. Another useful ability is to be able to run ad hoc CFML code without needing to spin up your CF engine. What if there was a simple text-based API that ran the same on Windows, Mac, or Linux to do all that?

Quick, how do you install the latest version of library XYZ into your site? (Please tell me you're using other developers' hard work and not writing everything yourself). If your first thought was "open up a web page and download a zip file", stop right there-- Brachiosaurus just called and he wants his workflow back. Other platforms have made their name in perfecting the art of gathering community libraries into one standardized format that can be searched for, manage dependencies, and downloaded with a simple command anywhere and any place. Forget the zip files-- what if you could just type "install XYZ" and go get another cup of coffee? And that ABC library that XYZ depends on-- don't worry it will be automatically installed as well.

Some of your day-to-day tasks might not seem so bad. So you create a new site for each new client every month with the same defaults and base libraries. You manually check every couple of months to see if any of your libraries have new versions. Every day you run your unit tests a few dozen times. And every time you need a new controller you copy the last one you made so you don't have to look up the method signatures again. Every one of those tasks should be scriptable and repeatable-- work smarter, not harder! What if you could create a "recipe" for a new site with all the goodies you like and just run the installation and setup with a single line of code to guarantee it was the same every time? Or what if running your BDD test suite was as simple as typing "testbox run"? You don't have time for boilerplate activities all day long, that coffee isn't going to drink itself!

A CLI, REPL, and Package Manager aim to help you be better, faster, and more powerful at everything you do. Come "up" your game and discover the power of CommandBox as part of your new everyday workflow. Go Commando!

0

ColdFusion And Railo SuperClass's Switch "this" Between pseudo-Constructor and Init()

ColdFusion, Railo

I noticed an interesting behavior this week that was a little unexpected.  The repro case involves two CFCs-- one extending the other and involves where the "this" reference points to.

Constructors

ColdFusion has two types of constructors-- that is, ways to run initialization code upon the creation of the component.  The first way is called the pseudo-constructor and basically refers to ANY code inside the component that is not part of a method. That was the only way to run initialization code back when CFCs first came out in CFMX 6.  The second way is via a method called "init()".  This was a widely-used convention for years before CF9 started automatically calling it for you when you used the "new" keyword and "entityNew()" function.

Narcissism or Schizophrenia

Sometimes components want to know about themselves or even talk to themselves.  Heck, I wrote a CFC last week that just won't shut up!  That's why there is a keyword called this available inside every CFC.  This is the same as the external references held by the code that created the component instance.  The pseudo-constructor and init() method both have access to this.

The Code

Here is our super class, or base class.  

animal.cfc

component {
	
	writeOutput( 'Animal pseudo-constructor. "this" name: #getMetadata( this ).name#<br>' );
	
	function init() {
		writeOutput( 'Animal init. "this" name: #getMetadata( this ).name#<br>' );
	}	
}

Here is our sub class or concrete class that is a more specific type of animal.  

dog.cfc

component extends='animal' {
	
	writeOutput( 'Dog pseudo-constructor. "this" name: #getMetadata( this ).name#<br>' );
	
	function init() {
		super.init();
		
		writeOutput( 'Dog init. "this" name: #getMetadata( this ).name#<br>' );
		
		return this;
	}	
}

Remember the new operator will automatically call the init() constructor method.

index.cfm

<cfset new dog()>

So as you can see, each component logs the name of the component as reported by getMetadata() in both the pseudo-constructor and init() constructor.

The Behavior

Here is the output.  It is the same for Railo 4.2, CF9, CF10, and CF11.

Animal pseudo-constructor. "this" name: animal
Dog pseudo-constructor. "this" name: dog
Animal init. "this" name: dog
Dog init. "this" name: dog

The this reference in both init() methods point to the "dog" component that I'm creating.  However, the pseudo-constructor code in the base class "animal" has a this reference to "animal", not "dog". What bothers be about this is:

  • The this reference changes unexpectedly in the base class
  • There is no way for the base class to access the concrete class in its pseudo-constructor
  • I can't find any Railo or Adobe ColdFusion docs that reference this behavior to show if it's expected or not.

That second bullet point is specifically what was tripping me up because the base class can't get a reference to the actual component being created.  Sean Corfield mentioned on Twitter that a base class should not know about it's sub classes, but use polymorphic methods. However that DOESN'T WORK since the base class's pseudo-constructor has no reference to the sub class at all.   To test this, put a speak() method in the dog CFC:

function speak() {
	writeOutput( 'Woof!<br>' );	
}

Now, try to call that from the base classes pseudo-constructor.  

speak();

No matching function [SPEAK] found

Of course, this works from the init method, but my point is I think it should work in both constructors.

Another interesting note is that if you save a reference to this in the base pseudo-constructor and check it later, it will have changed to the concrete class.  This made debugging a pain since I originally started appending references to an array in the request scope and dumping them after the component creation which yielded different results than the state of the this references at the point in time when the constructors were executing.

Conclusion?

I mentioned this on Twitter and got a couple different responses. What do you think?  Should CFCs handle the this reference the same between their pseudo-constructor and regular constructor?

 

10

Adobe Product Security Incident Response Team (PSIRT) On ColdFusion And HeartBleed

ColdFusion, General, Networking, Railo, Security

The world is abuzz with the OpenSSL "heartbleed" bug and the ColdFusion community has also been going 'round about it too.  Firstly, a server (like Apache, Nginx, Tomcat, etc) can be exploited by a client on a hackers machine requesting an SSL connection.  In addition, a client (CURL, wget, CFHTTP, etc) can be exploited if connecting to a malicious SSL endpoint.  So basically, the bug has the ability to flow both ways. 

For most CF sites, they are using IIS, Apache, or Nginx to serve content so ColdFusion has no bearing on the vulnerability from that end.  Any CFML application, however, can connect to a malicious SSL endpoint.  Of course, it only matters if the OpenSSL library is specifically being used.  Any other SSL implementation is safe.

To date, neither Adobe or Railo have yet to make public announcements via security bulletins or their official blog.

UPDATE April 17: Railo responds here.

UPDATE April 18: Adobe responds here:

There have been a handful of less "official" conversations in mailing lists and Twitter.  As best I can tell, neither Adobe ColdFusion or Railo use OpenSSL and therefore are safe.  Of course, any other parts of your web stack (even bundled libraries) might use OpenSSL.  Gert from Railo has promised a blog entry "soon" to address the issue regarding Railo.  There has been some complaining about the lack of official word from Adobe, and my understanding is that the ColdFusion team's hands are tied by the Adobe PSIRT who are the only ones allowed to comment publicly on security matters.

 The general consensus is they could certainly say something, even if it was simply, "Hey, we're looking into it and will get back to you soon".  That as it is, I E-mailed Adobe's PSIRT myself and got a reply that seems as close to an official reply as they are willing to provide at this point though I'm unclear why they're talking about it one-on-one but refraining from public statements.  For the sake of those who haven't E-mailed PSIRT, I will post their reply here for the benifit of the community until something official comes out.  Also, for funsies, I'll post my original E-mail plus my followup.  If I hear back again, I'll update this post.


From: Brad Wood
To: PSIRT@adobe.com
Date: Wed, Apr 16, 2014 at 5:45 AM
SubjectAdobe ColdFusion and Heartbleed

Dear Adobe PSIRT team, 

 
I would like to encourage you to please make a public announcement regarding Adobe ColdFusion and if it is vulnerable to the latest OpenSSL "heartbleed" bug. This is a very significant bug that has people around the world scrambling to patch their software.  Even if Adobe ColdFusion is not susceptible to the recent "heartbleed" bug I would strongly suggest making an announcement on your blog to state that or authorize the ColdFusion team to do so on their blog. 
 
Many people in the CF community have noticed the silence on this issue and an official announcement really needs to be made in order for your customers to feel safe and to verify with their employers that they have all the patches they need.  Communication is very important and I hate to see the Adobe ColdFusion team getting beat up for not addressing this issue publicly on their blog.  Please authorize them to make some kind of statement on this.
 
Thanks!
 
~Brad

From: PSIRT@adobe.com
To: Brad Wood
Date: Wed, Apr 16, 2014 at 1:39 PM
Subject: RE: Adobe ColdFusion and Heartbleed

Hello Brad,

 

Thank you for contacting us.  We appreciate your feedback.  Please note that ColdFusion does not use OpenSSL. However, customers who are using an external web server with their ColdFusion deployment (ex. Apache) should test for CVE-2014-0160. If affected, customers should follow the recommendations provided in the OpenSSL security advisory, available at https://www.openssl.org/news/secadv_20140407.txt. Adobe

also recommends consulting the ColdFusion lockdown guides for security best practices:

https://www.adobe.com/content/dam/Adobe/en/products/coldfusion-enterprise/pdf/cf10-lockdown-guide.pdf

http://www.adobe.com/content/dam/Adobe/en/products/coldfusion/pdfs/91025512-cf9-lockdownguide-wp-ue.pdf

 

We hope this information is helpful.  Please let us know if you have additional questions.

 

Thank you,

Adobe Product Security Incident Response Team


From: Brad Wood
To: PSIRT@adobe.com
Date: Wed, Apr 16, 2014 at 3:13 PM
SubjectAdobe ColdFusion and Heartbleed

Dear PSIRT Team, 
 
Thanks for the reply.  I appreciate the links and concern.  Let me be very clear though-- I am not asking about this for the sake of my servers, I am letting you know that Adobe needs to make a public official statement on the matter for the entire community to see.  Even if your blog entry said nothing more than what you put in your E-mail reply that would be great-- but the community has noticed the lack of public response by Adobe to this matter and it's reflecting quite poorly on your PR.
 
If the PSIRT team doesn't have time to make a quick announcement, please authorize the ColdFusion team to put out a blog post.  This would do a lot for the community as silence breeds distrust and most every other major technology stack have already addressed their platform publicly-- even if just to say they are not vulnerable.
 
Thanks!
 
~Brad
 

UPDATE April 18:


From: Brad Wood
To: PSIRT@adobe.com
Date: Thu, Apr 17, 2014 at 9:50 PM
SubjectAdobe ColdFusion and Heartbleed

Dear PSIRT team,

 
Can you please respond to the comments on my blog made by a community member named "Aaron".  He has listed several binaries that ship with ColdFusion that supposedly use OpenSSL.  His comments can be found here:
 
 
Also, if you haven't seen it-- here is the official response from the Railo team (a competitor of Adobe CF) which categorically addresses the uses of SSL inside Railo server.
 
 
Thanks!
 
~Brad

From: PSIRT@adobe.com
To: Brad Wood
Date:  Fri, Apr 18, 2014 at 2:58 PM
SubjectAdobe ColdFusion and Heartbleed

Hi Brad,

Thanks to you and Aaron for bringing this to our attention.  With your input, we started a deeper investigation of ColdFusion components.  We have also clarified our blog post regarding OpenSSL in ColdFusion (http://blogs.adobe.com/psirt/?p=1085).  Should additional information arise from our investigation we'll provide an update to our blog.

 

Thank you again for your help,

Adobe Product Security Incident Response Team

6

My First Experience With DataBoss Dynamic ORM Administrator

ColdBox, ColdFusion, ColdFusion Builder, ORM

With the release of DataBoss 1.3 today, I thought I'd share a quick story about my recent first project diving into DataBoss.  Full disclosure: DataBoss is a commercial product and I work for the company that makes it.  None the less, I thought it was pretty freaking useful so I thought I'd throw out this quick post.

For those of you who don't know what the heck DataBoss is-- it's a Dynamic ORM Administrator.  Basically, it can scaffold out CRUD (Create, Read, Update, Delete) screens for pretty much any database structure and it's all based on ColdFusion ORM.  It runs on Adobe ColdFusion as well as Railo and the minimum to get it running is to create ORM entity CFCs, drop them in your models folder and reload ORM via the interface.  It will pick up your entities, read all the relationships, and create all the screens necessary to manage the data in your database complete with formatting, validation, rich text editors, date dropdowns, etc.

So, the recent project I got assigned was for a company that does development services.  They had a project they had been working on for one of their clients that involved a nicely-normalized database of about 20 tables that supported a multi-lingual ordering and reservation system.  They had the front end system built out with ColdFusion but the problem was the deadline was getting very close and they weren't going to have to time build the backend of the system that allowed all the products, descriptions, and companies to be configured.  They needed to have a backend over to their client in a matter of days to start entering data, but there simply wasn't enough time to build one from scratch.

Enter DataBoss.  I was tasked with setting up a data-entry app they could use to manage their database until they had time to finish the backend.  The database that had already been built was well-structured and contained many examples of one-to-many, many-to-one, and many-to-many relationships.  I was given a backup of the data structure and a diagram that showed all the foreign key relationships.  Using Adobe's CFC Generator for ColdFusion Builder, I selected the tables via the RDS datasource view and stubbed out all the ORM entities in script.  Don't try to use the CF Builder plugin to create relationships.  It's horrible and you'll be sorry.  For just stubbing out the entities and the properties, it's pretty good though and saves a lot of time.

DataBoss is packaged as a portable ColdBox module which means you can drop it into an existing ColdBox app, or just deploy it as a small standalone app.  I chose the latter and dropped my ORM entities in the /model folder.  After adding my datasource name to Application.cfc and changing dbCreate to "none" the app sprang to life and displayed a list of all my entities in a drop down.  There's settings in a JSON file to control pagination as well as the internationalization of the DataBoss app itself.  DataBoss already comes bundled with German translations which was nice since this project was for a German company.  

At this point, I went through and configured all the relationships and added metadata to each entity and property that controlled how it displayed on the screen, what kind of validation it applied, and what form controls to display for each field.  After a bit of tweaking, we had really nice CRUD screens fleshed out that even used 24-hour clock and dd/mm/yyyy date formats to match the local standard.  I enabled the Basic HTTP Auth built into DataBoss, and it was ready to deploy publicly!  All in all, we had the entire admin finished and ready to deliver to the customer in just a few days.

I was pretty pleased with how easy it was to get working, and was a major saver for them to get the edit screens to their customer in time.  And now, they can use those ORM entities for future development on the application.  DataBoss Standalone is only 99 bucks which isn't bad considering the time it can save you.  Think about using it for that old legacy database you have no edit screens for, or to help you create your next database.  You can also download a trial to play around if you want.

Product Site:

http://www.data-boss.com/

Docs:

http://www.data-boss.com/docs/index.html

0

Modern JVM Languages and ColdFusion Venn Diagram

ColdFusion

2

Mainstream News About ColdFusion Venn Diagram

ColdFusion, Security

0

Know Python? Help ColdFusion Get Proper Script Highlighting On GitHub

ColdFusion, General, GitHub

It's bothered me for a while, that GitHub and Gist don't have proper syntax highlighting for full-script CFCs like this one.  

They handle tags fine, and even do script inside of a <cfscript> tag, but just leave full script components as black text all the way down the page.

 ColdFusion has allowed all-script components since version 9 which was released 5 years ago.  I always just assumed that GitHub was aware of the problem and someone somewhere was hard at work resolving it.  Silly Me.

GitHub uses this Ruby library to determine what language a while is written in:

https://github.com/github/linguist

Which in turn uses this Ruby wrapper to spin up the syntax highlighter:

https://github.com/tmm1/pygments.rb

But that library is just a proxy to this Python library that actually does the color coding:

https://bitbucket.org/birkenfeld/pygments-main

It looks like there's already a ticket from 2012 to add support and Ben Riordan took a whack at it last year with no luck.  So I've forked the Pygments library, but know nothing of Python so I'm asking anyone who does to help me get this figured out.  Since script already works inside <cfscript> tags, it sounds like all the pieces are there-- we just need to properly identify script components and use the correct highlighter for them. Comment here or shoot me an E-mail if you'd like to help!

4

Who's Had More Vulns- PHP, Java, or ColdFusion?

ColdFusion, General, Security, Technology

I get tired of people on complaining about ColdFusion as a technology choice because it's "so insecure".   I regularly am told that it has more holes, more vulnerabilities, and a worse track record than other platforms. That's why I compiled this quick chart showing the number of Common Vulnerabilities and Exposures (CVE) by year for CF as well as PHP and Java (as reported by cvedetails.com) which are two of the most-used languages on the web.  I also threw in Apache Tomcat for comparison since it completes in the web space and CF10 actually runs on a version of it.

 

Click to enlarge

So to break this down, the red line riding out on top with a huge spike in 2007, that's PHP.  The purple line coming out of the backfield for a solid lead (?) at the end is Java.  The yellow line is Tomcat who still manages 10-15 vulns a year (and the only one to go LOWER than CF.  And that green line on the bottom with the lowest number of vulns every year, and nothing even reported until 2006- that would be CF.

So, sure-- there's a lot more info than just the counts on the chart.  My point also isn't that PHP or Java are bad-- I'm just trying to make the point that oft-used technologies are targeted by crackers and nobody is perfect.  And according to this data, CF is doing way better than several of the main techs out there.  It should also be noted that CF, Java, and PHP were all created the same year-- 1995, so don't give me any of this "old" crap either.  (Tomcat was created in 1999)

References:

 

10