Timothy asks:
Are there security advantages to having cfc's located outside of the webroot in the gateway/cfc folder accessed through a mapping compared to having the cfc's reside inside the specific project in the webroot?
In general the only thing you have to worry about are people invoking your CFCs remotely. CFC methods, if you do not specify an access setting, will default to public, which means they can't access them remotely. So in order for your CFC to be insecure, you would have to go out of your way to set the method to remote.
Now with that being said - I view CFCs as resources like includes and custom tags, and therefore they have no place under web root anyway. Moving them out is better (imho) for organization. You can still provide a remote facade using proxy CFCs as services.
Archived Comments
Call me a noob but if I place the cfc's in the gateway/cfc folder and IIS points my site files to c:\inetpub\wwwroot\mydomain, then what path do I put in cfinvoke?
If yo use a cfmapping for the site root (not web root, the site, or project root), then you can make instances of the CFC.
How do you organize your CFC's when there are multiple sites running on the same server?
Not quite sure I get you. Are you saying you have multiple sites that need the same CFCs? If so, store them in some common folder, make a CF mapping (like /common), and address them there.
I've created a folder outside the webroot called, "org" which is mapped in Coldfusion as "org". Then I have subfolders for a namespacing type setup that I saw Ray using. For example, "I've got "org.camden.yahoo", "org.cflib" (for cflib functions), "org.esd112.service.something", "org.esd112.customtags".
So to answer Jason's question, I would create a 2nd folder under "org" (or "com" if you prefer) such as "org.siteA.something.somethingelse" and "org.siteB.stuff".
Works great. (BTW, thanks for the clarification Ray. I was wondering about the same question. :-)
@Ray I usually put my site specific CFC's in /sys under the site root. You said they should be put outside the site root folder. I'm curious how you setup your folders outside the root. Do you put them in a directory and then use a CF mapping for each site or do you have a common place that you organize by folders (i.e. What Dan is doing)
I did not say that. I said put them out of web root. I only suggested out of site root for CFCs that multiple siutes use.
Hey Ray,
Isn't it so that if you request a CFC directly with your browser you end up with the cfcExplorer introspective CFC documentation, or am I mistaken about how that works? If so, isn't it against best-practices to expose those kinds of guts? I'm not sure I'm 100% comfortable with it. Also seems to me like another one of those theoretical problems that is not dangerous to worry much about in the real world? Thoughts?
/Willy
You can only access CFC introspeciton docs if you know the CF Admin/RDS password, or if you have none set. That should never be true in production.
Oh YEAH... Ok, so that's not a problem. Thanks, Ray.
For what it's worth, we put our cfcs in an reversed-domain-name folder structure outside of our webroot, with a cf mapping directly to our edu/ folder. Now that this question has come up, I'm not completely sure WHY we do that, other than the good organizationally-specific name-spacing.
/w
I believe the reverse domain thing is common in Java packages. It is convention.
I completely disagree with the logic of moving your includes, custom tags and cfcs to folder outside of the webroot. this causes more headaches then it's worth when deploying the program.
Most people don't use ant or some other automatic deployment method. Most copy the files manually and then create mappings and what not through cf administrator.
By moving these file out of the web root, now you have to remember to copy those folders as well AND remember to create a mapping for it in CF administrator. Although CF8 allows us the ability to create mappings through the cfmapping tag, you could still be restricted by the ftp process. If you only have access to your web root folder when ftpping into the site, then what good was moving the files to an outside directory for development in the first place?
A better solution (in my opinion) is to put all of your custom tag, includes and cfcs under a directory in your web root and then create an application.cfm file for that directory that does nothing but about the request.
Now your application doesn't require a mapping for it to run and your code is safe from someone trying to execute it remotely (though I don't see how you would execute an include, custom tag or cfc remotely.
@Tony:
Wow, lots of comments here.
First off - I'm not sure what FTP program you are using. I have no issues moving amongst folders. Having folders in and our of web root is no different than having sub folders under web root. If you have to navigate to upload a JS file, than what's the big deal about navigating to upload a CFC? Unless you put ALL your filers in one folder (I hope not!) than you must be moving around so that argument doesn't hold any water with me.
Secondly - if you use shared hosting and just have a web root, then the argument is moot. Yes you must stay under web root. But if you have access to a 'real' server or VPS, then you can use whatever.
Thirdly - if I can simply put my resources out of web root, I don't have to worry about adding a bunch of app.cfm files just to 'suppress' the loading of these files. In my mind, that is simpler. Why write security to block access to a resource when you can simply remove the resource from the web root.
For code that is not site-specific, I put it in the CustomTags folder or a subfolder thereof (CustomTags/com/sebools, for example). This makes those resources universally available without the need for a mapping (one less thing to think about).
For site-specific CFCs, the location doesn't really matter. Unless the access is "remote", then they are safe.
For site-specific custom tags, I don't think it really matters (so long as you use Application.cfm to secure them if they aren't in the web root). It isn't a bunch of app.cfm files, just one. That really isn't much trouble.
The point is that either way works, but I would hate for people who are in a situation where they don't have easy access beyond the web root to worry that they aren't secure.
Well technically they ARE less secure. How many people run their custom tags and includes directly to see what happens? If you can't move your files out of web root, then you must use an app.cfc/cfm 'block' as you suggested. I -do- want people to think about this.
Assuming that you are using Application.cfm to prevent access, how are they less secure?
That's what I said though - you have to write code to make it secure, whereas my way just keeps em out of web root altogether.
How does this work with cfgrid? I made a mapping in the administrator to a folder off the web root but when I try to bind a cfc in cfgrid it says it can't find it.
Because CFGRID is making an Ajax based request. If you can't hit your CFC in the browser, neither can CFGRID. YOu need to use a proxy to point to the CFCs outside of web root. A CF mapping is not the same as a web mapping.
I've got clients with all types of server configurations: shared, in-house, and dedicated co-location. I use mappings for all of these configurations and keep CFCs, UDFs, custom tags, etc. outside the web root. The web root in shared hosting doesn't HAVE to be your "site root" or "account root". When I set up new shared sites I simply request a "www" folder be created in my site root directory and specify that folder as the web root. If a host won't do that for you, I'd suggest moving to one that will.
I have two instances of an application in same server. When i try to run a component from one instance its taking the component in the other instance ( the component in the same instance is not running ) since the directory structure is similar in both. What i have to do to get this solved? i want the corresponding component to be run from the instance it is called.. please help
Are both apps using the exact same name?