ColdBox Blog

ColdBox Connection 4/23 Noon Central on JS and CSS Workflows

Brad Wood   |   April 22, 2015

 

We're having another ColdBox Connection Thursday the 23rd at noon central time where special guest Jon Clausen will share how to work with static assets like CSS and JavaScript.  Things he'll cover:

  • Workflows and Dependency Management for CSS and Javascript with Bower
  • Optimizing production CSS and Javascript using NPM and Grunt
  • Be the boss of your CSS with SASS  (Depending on the level of experience with this on the call, I can be brief or go a little further in depth)

And if we have enough time, we'll try to touch on these topics as well.

  • Migrating from Apache: Running blazing fast Coldbox Apps with NGINX/Lucee
  • Automating Coldbox and CFML deployment (and rollback) on ACF and Railo with Capistrano

The show will be in our regular Adobe Connect room.  See you then!

http://experts.adobeconnect.com/coldbox-connection/

The recording will also be posted here:

http://www.coldbox.org/media/connection


Bypassing ColdBox's Error Handling

Brad Wood   |   April 10, 2015

 

Error handling is one of those important things that many developers neglect.  Your code never errors once you're done testing it, right :) ColdFusion's detailed error messages were always a draw to the platform, but have become a bit of an embarrassment when surfing across a site that's sporting the default, ugly error page because the developers didn't bother to even implement a global error handler. 

When you use ColdBox, errors in your code are handled automatically by the platform.  There are very few features of ColdBox that kick in by default but this is one of them and we feel it's for very good reason.  ColdBox's debugging screen is not only prettier, but it displays a plethora of additional information to help you troubleshoot.  In ColdBox 4, we took it a step further by making ColdBox's default error template secure-by-default.  This means if you install ColdBox, don't change a single setting, and push it to production, errors on your site won't be advertised in juicy detail to the first hax0r that surfs across.

ColdBox's error handling is also incredibly powerful.   There's no need to litter your code with try/catches to ensure all errors are handled.  The framework will capture any error and gives you several ways of handling that error, whether it's the onError() convention in your handler, the exception handler event, or an interceptor.  Take your pick.  You can read about all these options here.

http://wiki.coldbox.org/wiki/ExceptionHandling.cfm

Perhaps surprisingly, this blog isn't about any of those options.  I wrote this up to describe how to completely BYPASS ColdBox's exception handling.  I've only heard one person ever want to do this, but they suggested that perhaps others had wondered the same thing and simply not voiced the question.  Honestly, I'm not sure why you'd want to bypass a perfectly good, extensible error handling subsystem to write another one from scratch, or just leave your site unsecured, but I suppose it's possible you just really like the colors of the default error template.

To cause your exceptions to bubble up out of the framework, simply put this bit of code in your /config/ColdBox.cfc somewhere outside of the configure() method.

function onException() {
  throw( object=interceptData.exception);
}

Yep, it's really that simple.  The magic that lets this work is the fact that your ColdBox configuration file itself gets registered as an interceptor.  This means you can create interceptor methods right there in your config file and they'll get registered.  In this case, we're listening to the onException interception point, then simply re-throwing the exception object.  This will promote the exception up to your Application.cfc's onError() method, or if that isn't defined, the global error template defined in your CF Administrator.

 


Attention: MessageBox is Now a Module

Scott Coldwell   |   February 27, 2015

 

The beloved MessageBox plugin has been a staple of the ColdBox platform since the beginning. With ColdBox 4.0 it's still available, but if you don't need it, you have the freedom to leave it out.

The new modular approach (and deprecation of plugins) of ColdBox 4.0 means much of its built-in functionality has been moved to separate, installable modules. One of the many new modules introduced with ColdBox 4.0 is the MessageBox Module. To install, simply fire up CommandBox:

box install cbmessagebox

 

For the plugin, you might have had code like this:

getPlugin("MessageBox").info( "Hello" );

With the module, your syntax changes slightly to:

getInstance("messagebox@cbmessagebox").info( "Hello" );

or, leveraging WireBox:

property name="messagebox" inject="messagebox@cbmessagebox";

...

variables.messagebox.info( "Hello" );

 

Happy messaging!


ColdBox 4.0 Removed Plugins

Brad Wood   |   February 26, 2015

 

ColdBox Plugins have graduated to become just models. The plugins convention has been removed and all references to plugin injection or DSL's are gone. You must now place all your plugins in your models directory and request them via getInstance() or getModel() calls.


Plugins are an old ColdBox convention but their baggage doesn't really serve a purpose now that we have modules for easy packaging of libraries and WireBox for easy creation of CFCs. Neither of those existed back when Plugins were birthed. It's time to say goodbye to the concept of plugins, but all their functionality will still be here, just with a slightly different (and more standardized) way of creating them.

Read More...

The UDFLibraryFile setting is now "applicationHelper"

Scott Coldwell   |   February 25, 2015

 

If you have a ColdBox config setting UDFLibraryFile, then you'll want to change it when upgrading to ColdBox 4.0. It functions the same, but is now called applicationHelper.

applicationHelper is an optional setting where you can declare the path to a UDF template to load for usage in the views, layouts and event handlers. You can use relative paths to your application's root or ColdFusion mappings.

For example if I have my udf template called udf.cfm in my includes directory I would use:

component hint="ColdBox Configuration" {

	function configure(){
		coldbox.applicationHelper = "includes/udf.cfm";
	}
}

Or if I have them in a mapping called myudfs, then I would use:

applicationHelper = "/myudfs/udf.cfm";

You can also use an array to declare multiple paths:

applicationHelper = ["includes/udf.cfm", "/myudfs/udf.cfm"];

 

See what else is new in ColdBox 4.0!


Module Bundles in ColdBox 4

Luis Majano   |   February 24, 2015

 

With the advent of so much more functionality in modules, in ColdBox 4 we added the ability to group modules in a single directory we lovingly call The Module Bundle.  This feature became a reality due to a real client's need of being able to logically separate modules into logical buckets.  His application had an extensive amount of modules and he wanted to further segregate them, thus module bundles became a reality.  

 

 

Module bundles does not add extra functionality or features to the framework, but it is a mere logical boundary between modules.  It will allow you to create a folder with the convention {name}-bundle, notice the bundle suffix.  Then you can drop any amount of modules and sub-modules within it.  You can even drop in module bundles inside of it as well.

 

coldbox-bundle
  * cbstorages
  * cborm
  * cbsecurity

 

In ColdBox 4.X we will introduce the ability to package these bundles via CommandBox and even deliver them as a coldbox.bundle archive, which ColdBox will know how to unpack and install.


The Storages Module

Curt Gratz   |   February 23, 2015

 

If you have been following our series here on ColdBox 4.0, you are probably sensing a theme.  

Another major change in ColdBox 4.0 was the removal of plugins as a thing.  They were just model objects anyway and we had treated them as such within the framework for some time.   However, because of that, we needed to do something with some of our various "core" plugins.  So sticking with our aforementioned theme, many of them were converted into modules.  

We decided that we could bundle a few of our old "core" plugins that had similar functionality together into one module.  The Storages Module.  This module consists of what was the

  • Session Storage Plugin
  • Application Storage Plugin
  • Client Storage Plugin
  • Cluster Storage Plugin
  • Cookie Storage Plugin

To install The Storages Module using command box simply use the following command.

box install cbstorages

If you have existing calls to the old plugins such as 

getPlugin( 'SessionStorage' )
getPlugin( 'ApplicationStorage' )
getPlugin( 'CookieStorage' )
etc...

Then after you install the module you can replace those with

getInstance( 'sessionStorage@cbstorages' )
getInstance( 'applicationStorage@cbstorages' )
getInstance( 'cookieStorage@cbstorages' )
etc...

We didn't make any changes to the API of the objects so everything should work as always after that.

Now...Module all the things...


ColdBox 4.0: What We Kept

Nathaniel Francis   |   February 20, 2015

 

ColdBox 4.0 is a major release for the ColdBox line. The most major since its original release in June 2006. To boost efficency and open up options, we've removed a lot of non-necessary items from the core installation and made them available through modular architecture instead. However, there are some thing that we've kept - and for good reason. This post discusses what we kept in the core of ColdBox 4.0 and why.

Read More...

CSRF Security Module: Not All Surfing Is Good

Nathaniel Francis   |   February 20, 2015

 

Welcome to the jungle

Remember a time when the internet was a safe place. Where your email wasn't getting hacked every 3 months, nobody wanted to XSS something malicious to you or through you, and no one conceived of encrypting your hard drive for money?

I don't either. Since its inception, the internet has been a jungle of security complications.

CSRF: not the good kind of surfing

This discussion could quickly dive into a host of security complications and safety precautions that we, as developers should be paying attention to. Instead, I'm going to focus on one security breach and a modular technique that ColdBox 4.0 provides to help us developers fight against it.

CSRF aka "Cross-Site Request Forgery", commonly pronounced "sea-surf", is a web exploitation where the offender violates the trust between a website and a user's browser. I know that's vague. There are various forms that CSRF takes, but they all boil down to the website being violated by the user's browser in some way, shape, or form. This is just the basic idea. The whole story is worth a decent Google search.

We got a module for that!

As with any multi-faceted security aspect, there is no singular answer. If a burglar can come into your house through either the window or the door, you may want to shut and lock both, or get a guard dog, or move. However, with CSRF security violations, there is one common flaw. The violation of trust comes from triggering actions on your site without your consent. That we can handle.

The ColdBox Cross Site Request Forgery (CSRF) Tokens module generates tokens that generate a verification, "secret handshake" system between your server and the browser. This added layer of security is subtle, but powerful in CSRF violations because it prevents a foreign agent from violating the trust between browser and server.

To install the ColdBox Cross Site Request Forgery (CSRF) Tokens module, simply go to CommandBox and enter:

box install cbcsrf

The ReadMe for this module includes the following simple example of how to use the CSRF module's functionality:

component {
    any function signUp(event, rc, prc) {
        // Store this in a hidden field in the form
        prc.token = generateCSRFToken();
    }

    any function signUpProcess(event, rc, prc) {
        // Verify CSFR token from form
        if(verifyCSRFToken(rc.token) {
            // save form
        } else {
            // Something isn't right
            setNextEvent( 'handler.signup' );
        }
    }
}

The ColdBox Cross Site Request Forgery (CSRF) Tokens module is a simple, elegant solution to a common security problem.


ColdBox 4.0 Dealing With Datasources

Brad Wood   |   February 19, 2015

 

ColdBox allows you to store the details of your CF datasources in your configuration file.  This prevents you from needing to store usernames and passwords in  your actual code, and allows you  to easily switch an application to another database, even with the environment control.  In  the past this datasource information was presented to you as a CFC object with getter methods.  

In ColdBox 4.0 we recognized that the datasource bean was really just a value object with no behaviors-- only data.  In the spirit of simplification,  we've replaced the datasource bean with a standard struct of data.

Read More...

ColdBox Book

book