A user asked this about the cfajaxproxy tag:
Any way around CFAJAXProxy exposing all remote component functions to JavaScript? To elaborate, I have a component with x remote functions. A particular page call requires only one of these remote functions. I'd like CFAJAXproxy to expose only the required functions.
When I first read this - I was a bit confused. Why expose a method as remote if you didn't want it - well - remote? Turns out he was using one CFC for his public facing site as well as his Admin.
So the short answer is that there is no way to tell cfajaxproxy to just expose certain methods. The long answer is that there are multiple ways around this.
First off - don't forget that when your browser makes an Ajax-based call, it is just like a "normal" call. This means the Ajax call shares your session. So if your CFC methods had session based security of some type, or roles-based security, then you need not worry.
The other possibly way to handle this is to take all those methods and make them access="public" instead of remote. Then build a public facing CFC that has access to the CFC methods it needs. Another CFC would then handle accessing the other methods. You still need to secure the methods though. Do not assume that someone won't guess at the location of the admin CFC.
But at least with the second method - you have one core CFC with the logic - and your "proxy" cfcs simply handle security and handling off the calls to the core CFC.
By the way, the user said he suggested to Adobe that they extend the cfajaxproxy to support this. Here is what he suggested:
<cfajaxproxy cfc="cfc.widgets" jsclassname="widgetFactory" exposeTheseMethods="Widget1,Widget2,Widget3" OmitTheseMethods="SecretWidget">
I'm not so sure I like this. It may give you a false sense of security. If secretwidget was method="remote", then you still have a possible security hole if someone can guess at the method name.
And lastly - I still say cfajaxproxy is the coolest tag in ColdFusion since cfdump. Anyone using it in production yet?
Archived Comments
I agree, that extension of the tag doesn't make sense. In my opinion you should write a remote facade to remote any methods, thereby only exposing the ones you want. I never use the same component for my app as I do for remote. This also allows me to take into account any differences that might need to be accommodated in the data for a remote version of the methods (though usually there isn't any).
I think the cfajaxproxy tag is awesome too! I have a public facing prototype of my open-source list using it (as well as a number of other CF8 Ajax tags) that is available at:
http://www.remotesynthesis....
It uses cfajaxproxy to handle retrieving the record detail of the item you click. I am trying to figure out however why the initial load of the grid is sometimes *very* slow.
I think I would put cfdiv up there on the same coolness level as cfajaxproxy. We're using it in production (www.interfolio.com). Since cfdump? Hmmm, might throw cfdocument in there but then I've been doing a lot of pdf work the last couple years. But its definitely on that level.
I agree with you on the security ramifications and there is no need for the expose and omit attributes.
The obligatory note that ColdSpring can automatically generate remote proxy objects that expose only the methods you specify.
I'm the type of guy that doesn't like to waste resources, and have cleanly formatted source code (even if they are client side). Using cfajaxproxy causes ColdFusion to write JavaScript that exposes all remote component functions. If you look at the source code of a “proxied” page you will find JavaScript like this:
(Widgets never get old)
var _cf_Widgets =ColdFusion.AjaxProxy.init('/cfc/Widgets.cfc','Widgets');
_cf_Widgets.prototype.setWidget1=function() { return ColdFusion.AjaxProxy.invoke(this, "setWidget1", {});};
_cf_Widgets.prototype.setWidget2=function() { return ColdFusion.AjaxProxy.invoke(this, "setWidget2", {});};
_cf_Widgets.prototype.setWidget3=function() { return ColdFusion.AjaxProxy.invoke(this, "setWidget3", {});};
_cf_Widgets.prototype.setWidget4=function() { return ColdFusion.AjaxProxy.invoke(this, "setWidget4", {});};
...
Now, why would I want to see all my remote methods on the page if I'm only going to use one of them?
Every time a function is set it wastes Client side browser memory, I know it's very little...but I'm anal.
Has anyone else had any problems using this tag under linux?
for example..
<cfajaxproxy cfc="proxy" jsclassname="proxy" />
Throws an error that /proxy.cfc can't be found if the directory is something like this.
http://127.0.0.1/andrews/index.cfm
And the /andrews/ is an alias to another directory..
Can you hit http://127.0.0.1/andrews/proxy.cfc in your browser?
Yes I can.
In firefox, and using the index.cfm?cfdebug option I can see that it is trying to load the proxy.cfc from /proxy.cfc
So I am at a loss?
I believe CF will try and find the cfc in the file system, which, in this case it won't be able to. It does this to verify the cfc exists. Although thats not gonna help much in your configuration...
@Sam - Yes I am aware of this, and my belief like all cfc's it should be found from the current called template. So the problem I see is if I have an alias /andrews and browse http://127.0.0.1/andrews/proxy.cfc it is found.
But <cfajaxproxy cfc="proxy" jsclassname="proxy" />
Tries to find the proxy.cfc at /proxy.cfc, so the problem I see is this how do you chenge this and load it from another location. Because to me this is saying that all ajaxproxies have to be in the root.
Hope that makes a bit more sense of the problem I am seeing.
Andrew,
I had the same exact problem with IIS(6). I had IIS home page setup on a network directory and a virtual directory on another machine...I was running my app on the aliased directory. I thought the cfc mapping in the CF admin would be sufficient enough to find the CFC but ColdFusion kept trying to map to my root like yours "/componentxxx.cfc" instead of "/cfc/componentxxx.cfc". Instead of using the aliased directory I mapped IIS home to the root of my app and it was fixed. I think it's a bug in CF8. Haven't tried this but try placing your component in another aliased directory and call it like cfc="cfcWhatever.proxy".
BTW did you try calling it like cfc="andrews.proxy"?
Yaron,
This is an apache alias not a cf mapping, and yes I did try your suggestions to no avail.
I had the same problem with aliased directories in IIS7 so I moved my components to a directory off CFIDE (not an aliased directory) and it worked fine.
Two notes:
1) Create an empty Application.cfm or cfc with just session management in the CFC folder
2) Dir structure should be "ProjectFolder where main application.cfm is / CFC containing FOlDER / then CFC file name with no extention" ex: childroot/cfcs/proxy when using CFC for url just use the absolute or relative path to the proxy.cfc
Thanks!