RE: [coldbox:16267] [coldbox-3.5.2] Initial config of Application.cfc

Communities ColdBox HMVC
1

Hello Adam, and welcome to ColdBox :slight_smile: Sorry for the delay in your post, the Google Group requires moderation for the first post.

If you’re not planning on using proxies for stuff like Flex or Ajax, then you can largely ignore the app mapping setting. Back in the day, the onus was on the developer to set that if the app wasn’t in the web root. Nowadays, the framework automatically detects the directory it’s in when it boots up. The setting still exists in application.cfc but is only used for bootstrapping the application if the first request to it is not in it’s root folder. Regarding the slashes or dots-- either one will work. ColdBox/ColdFusion is smart enough to figure it out.

Basically, all you should need to do is have CF resolve “/coldbox” to the folder that contains the framework. This can be achieved by either placing the “coldbox” folder in the web root with that name or creating a mapping (server, or app-level doesn’t matter) that maps “/coldbox” to whatever folder contains the “system” folder. The mapping you described looks correct. The getting started docs do suggest simply dropping it in the web root because it’s the simplest way to get up and running. There’s also little someone can do it they try and hit the framework files directly. They’re pretty much all CFCs and have no remote methods. That being said, I think the majority of people leave the CB folder outside the web root and just use a mapping.

The difference between the regular application.cfc and the no inheritance one is just a choice we give developers based on what they want to do. I think most people use the application.cfc that inherits from a core coldbox file just because it’s the default and it’s the cleanest way to get running. The no inheritance version simply creates an instance of the framework (instead of extending it) to boot strap and passes the initial settings in.

So, I’m unclear from your E-mail if you are actually getting an error message, or were you just at the question-asking stage. Have you loaded the root of the sample app in your browser yet and do you see an error message? It’s pretty hard to screw up the sample apps :slight_smile: As long as /coldbox resolves and you hit the code it should work.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

2

Response inline. Anything deleted is fine / doesn’t warrant further comment.

Hello Adam, and welcome to ColdBox :slight_smile: Sorry for the delay in your post, the Google Group requires moderation for the first post.

No worries mate, I completely understand.

Nowadays, the framework automatically detects the directory it’s in when it boots up. The setting still exists in application.cfc but is only used for bootstrapping the application if the first request to it is not in it’s root folder. Regarding the slashes or dots-- either one will work. ColdBox/ColdFusion is smart enough to figure it out.

Cool, thanks. Might the docs benefit from a tweak then? Whilst what you say here is good, I’m not sure that’s borne out by how the docs read?

The getting started docs do suggest simply dropping it in the web root because it’s the simplest way to get up and running. There’s also little someone can do it they try and hit the framework files directly. They’re pretty much all CFCs and have no remote methods. That being said, I think the majority of people leave the CB folder outside the web root and just use a mapping.

Well yeah. That sort of rationalisation is akin to suggesting someone saves ALL their work on their desktop, as that’s more convenient. It’s not good advice though. Equally, whilst in the normal sequence of events it’s no prob having files not-intended-for-browsing to be exposed to browsing, that’s not how the notion of security works. The more stuff you expose, the more potential vectors you are offering for security violations. I think it’s not ideal to be encouraging “sub-optimal” practice like this: I believe “expediency of getting up and running” should not trump “doing things properly” (where there’s a bigger picture than just getting ColdBox working).

But anyway, you’re in good company with the advice you give, so it’s no prob, not surprising, and not a big thing. I mean the above as more an observation than anything else.

The difference between the regular application.cfc and the no inheritance one is just a choice we give developers based on what they want to do. I think most people use the application.cfc that inherits from a core coldbox file just because it’s the default and it’s the cleanest way to get running. The no inheritance version simply creates an instance of the framework (instead of extending it) to boot strap and passes the initial settings in.

Ok, I might need clarification here. Refer to this page: http://wiki.coldbox.org/wiki/Installation.cfm (subheading Alternate Installation Methods > ColdFusion Mapping):

ColdBox can also be installed by creating a /coldbox mapping in your ColdFusion server administrator or in your per-application mappings. Please also note that the application templates have two Application.cfc files, one with inheritance and another without inheritance, so you can use per-application mappings in the non-inheritance approach.

(my emphasis)

I guess I might have been misreading this y/day, as I took this to mean if one is using a CF mapping (as I will be), then I need to use the non-inheritance approach, because if I’m identifying the Coldbox location via a mapping in my own Application.cfc, I can’t then specify “coldbox.system.Coldbox” in the extends attribute of the component. Because at the time CF needs to know the extends value, it won’t know about the mapping that maps “coldbox.system.Coldbox” to a location. Wow. Dunno if that makes sense.

Anyway, you seem to be suggesting I could use the non-inheritance approach somehow, even though I am using an application-specific mapping…? Maybe we have wires crossed there.

So, I’m unclear from your E-mail if you are actually getting an error message, or were you just at the question-asking stage. Have you loaded the root of the sample app in your browser yet and do you see an error message? It’s pretty hard to screw up the sample apps :slight_smile: As long as /coldbox resolves and you hit the code it should work.

I’m not at the point of running any code yet. Perhaps unusally for one of your new users, I am critically evaluating your documentation as much as I am your software. So I am following the documentation literally, to see if it enables me to use the software (if that makes sense). The background to this is - as you know, but perhaps the other readers here do not - is the blog article I wrote here: http://adamcameroncoldfusion.blogspot.co.uk/2012/10/ive-picked-framework-well-youve-picked.html.

Unfortunately I’ve not had much time to dedicate to this yet, but I hope to get cracking with it today / this evening.

Thanks for your help, mate.

3

Adam, welcome.

But lets take what your stating below, just to help make it a bit clearer.

The mapping to ColdBox is actually used so that the framework can load and do its magic, when the core ColdBox application is not in the webroot, best way to look at this is that it is treated with any similar mapping needed to load components that are not going to be stored in the webroot.

The inheritance is pretty much personal choice, for example if you have a per application mapping then you would not be able to do inheritance, unless the coldbox mapping was defined inside the ColdFusion Administrator.

Its pretty much the same as any normal component, if you want to take that thought of thinking.

4

I think - given the recent CF exploits identified - it might be timely to revisit this approach of yours. Adobe allude to what I say in their security doc:

(the […] omissions are to simply focus you on what I mean, they do not change the context of the guidance)

Anything that is not intended to be browsed to is “unnecessary”.

And the current situation demonstrates that exploits don’t take advantage of the front door, they go in through a window around the back. So that all those files are “safe” from a “browsing from the front-end” perspective does not mitigate the fact they are possible vectors for attack.

Of course it’s up to you to evaluate the risk / convenience trade off here. I’d be even more emphatically stressing “don’t have files not intended for external access homed in an externally accessible location” though.