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

[br...@bradwood.com]

Hello Adam, and welcome to ColdBox :)  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 :)  As long as /coldbox resolves and you hit the code it should work.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

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

-------- Original Message --------
Subject: [coldbox:16267] [coldbox-3.5.2] Initial config of
Application.cfc
From: Adam Cameron <adamcamero...@gmail.com>
Date: Tue, October 16, 2012 7:21 am
To: col...@googlegroups.com

G'day
I've never used ColdBox before.

I am creating a "hello world" app as a dry run for using ColdBox for more serious things, but am pretty much blocked immediately, due to not quite getting your docs.

My dir structure is this:
D:\websites\www.scribble.local\ <= webroot & CF root
D:\websites\www.scribble.local\shared\git\frameworks\coldbox_3.5.2 <= where I intend to create /coldbox mapping
D:\websites\www.scribble.local\shared\git\blogExamples\coldbox\helloworld <= where the app is (ie: Application.cfc is in this dir)

This is just for the same of messing around, ultimately the dir structure will be along these lines:
D:\webroots\cf10\ <= CF root
D:\webroots\cf10\frameworks\coldbox_3.5.2 <= where I intend to create /coldbox mapping
D:\webroots\cf10\websites\myApp <= web root (ie: Application.cfc is in this dir)

I've followed through the docs, thus:
http://wiki.coldbox.org/ => http://wiki.coldbox.org/wiki/Dashboard.cfm#Installing_.26_Getting_Ready_For_Development => http://wiki.coldbox.org/wiki/Installation.cfm => http://wiki.coldbox.org/wiki/Bootstrapper.cfm

I followed my nose through this path to the "Bootstrapper.cfm" page because my coldbox dir is not going to be in the webroot (I find it quite strange that your baseline advice is to have the framework files in the webroot, btw?)

I've copied coldbox_3.5.2\ApplicationTemplates\Advanced\Application_noinheritance.cfc into the helloworld dir, and renamed it Application.cfc

I've opened it up, and are flummoxed by this guidance:
COLDBOX_APP_MAPPING
The application mapping is ESSENTIAL when dealing with Flex or Remote applications. This is the location of the application from the root of the web root. So if your app is at the root, leave this setting blank. If your application is embedded in a sub-folder like MyApp, then this setting will be /MyApp.

OK, so I will not be using Flex or remote applications... but on the other hand, the app (by which I am presume you are meaning my "helloworld" app, not Coldbox?) is not in the webroot, so I am guessing I need a value in here.  I don't think this is particularly clear.

So should this setting be (given my example above) /shared/git/blogExamples/coldbox/helloworld ? This was my assumption until I saw the example below, which was this:

<cfset COLDBOX_APP_MAPPING   = "apps.myApp">

Note that this seems to conflict with the earlier guidance, which indicated this should be a slash-based path, however this example uses a dotted path.  And it also doesn't seem to bear any relation to the example further up either, eg: the earlier example value was /MyApp, now we've got apps.myApp.  This makes me think these are two different things, but the docs are unclear.

I was hoping to see an example Application.cfc along the lines of "if your app is here, and ColdBox is here, then this is what the Application.cfc will look like".

Also, I'm doing all this because I'm following the "you're gonna need an application-specific CF mapping for your config", but there's no mention of CF mappings on this page.  Should I just presume there's nothing further to add, and I just need this in my Application.cfc

this.mappings = {
    "/coldbox" = expandPath("/shared/git/frameworks/coldbox_3.5.2")
};

?

--
Adam

--
--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To post to this group, send email to col...@googlegroups.com
To unsubscribe from this group, send email to coldbox-u...@googlegroups.com
For more options, visit this group at http://groups-beta.google.com/group/coldbox
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org
 
 
 

[Adam Cameron]

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

On Tuesday, October 16, 2012 5:33:15 PM UTC+1, Brad Wood wrote:

Hello Adam, and welcome to ColdBox :)  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 :)  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.

--
Adam

[Andrew Scott]

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.

-- 

Regards,

Andrew Scott

WebSite: http://www.andyscott.id.au/

Google+: http://plus.google.com/113032480415921517411

On Thu, Oct 18, 2012 at 1:31 AM, Adam Cameron <adamcamero...@gmail.com> wrote:

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

[br...@bradwood.com]

Thanks for the feedback on the confusion portions of our documentation.  I'll make a note to try and standardize our appMapping sample code. 

We've had a number of debates over the years on the list about whether or not it is ever valid to put the ColdBox framework in the web root and not surprisingly there are advocates on both sides.  For the foreseeable future, we'll most likely leave that in our docs as it is a valid way to get the framework running some there are additional security measures that can be deployed to restrict access to an acceptable level.  I'll make a note to check the docs and see if we have a best practice guide that covers the location of the framework files.

RE: mapping.  Yes, what you said makes perfect sense and I think you are on target.  It is true that the app-specific mapping is mutually exclusive with the inheritance Application.cfc for the reasons you stated.  If you are planning on use an app-specific mapping, then you are on the right path with the no-inheritance Application.cfc.  Sorry for the confusion there.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

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

-------- Original Message --------
Subject: Re: [coldbox:16271] [coldbox-3.5.2] Initial config of
Application.cfc
From: Adam Cameron <adamcamero...@gmail.com>

Date: Wed, October 17, 2012 9:31 am
To: col...@googlegroups.com

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

On Tuesday, October 16, 2012 5:33:15 PM UTC+1, Brad Wood wrote:

Hello Adam, and welcome to ColdBox :)  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 :)  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.

--
Adam

[Adam Cameron]

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:

Remove any [...] unnecessary ColdFusion components or templates from the [...] webroot directories.

(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.

--
Adam