The next few posts in my security series will be delayed. I have been busy with some other projects, as you are about to read. I hope to have them out by the end of this week, or early next week.

So my journey into the world of Object-Oriented Programming has begun, and I am really excited about it. It is definitely a different way of thinking about programming. So far there are things that I like, things that I really like, and things that will take getting used to. There has not been a single thing that has made me say that I dislike OO (so far).

[More]

UPDATE: So after reading Ray's Post here and after reading the comments on that post, I think I have to agree with my commenters as well as Ray's that this is not the best idea. The level of complexity that this adds does not make it worth the extra security (perceived or otherwise) that the technique may offer.

For my first security series post, I am going to keep things simple. This one is more of a tip/best practice than an article. At least, that is how I am planning it in my head, we'll see if that changes by the bottom of the page.

Today I want to discuss something that most developers and administrators will find to be very annoying. I know I do.

[More]

I have seen some comments around the interwebs about ColdFusion 8 application specific mappings solving the problem of using frameworks in shared hosting environments and in environments where global mapping is discouraged. I know that I have come across at least one situation where this is not the case, and I though I would share.

Don't get me wrong, I think application specific mappings are wonderful, and the commenters are mostly right in what they say, in MOST cases, application specific mappings will make hosting in a shared environment much easier.

Firstly, one caveat to having Application Specific Mapping on your shared host is for them to allow it. Of course, the advice here is, if they won't allow it, go elsewhere. There are plenty of other hosts out there that will allow it.

The second issue can be seen in this little snippet from Application.cfc on a standard Mach-II site.

  
<cfcomponent displayname="Application" extends="MachII.mach-ii" output="false">
<cfset this.name="AppName">
<cfset this.loginstorage="session">
<cfset this.sessionmanagement="true">
<cfset THIS.mappings["/MachII"]="c:\MyFrameworks\MachII">
...
</cfcomponent>
  
	

If you see the problem, raise your hand.

Of course, the problem is, the Application.cfc is Extending MachII.mach-ii before we are able to declare the mapping for MachII. This means that any existing mapping would override our and it would mean that if the MachII folder was not at the root level of the site, that the application would not be able to find it at all.

There are two solutions to this, the first being to move MachII to the webroot. The second option is to create a server side mapping. Now to be a good Shared Hosting Neighbor, you do not want to create a global mapping called MachII, since others on the server are probably using a different version of MachII than you. So you should create a server-side mapping with a unique name. For example, I would place my MachII folder in c:\wwwroot\MyFrameworks\Robot\. Then I would have my host create a mapping called "/robot".

Now, I can extend robot.MachII.mach-ii and then create my application specific mapping to "/MachII", using the same copy of MachII, for the rest of the app to use.