Ask a Jedi: Remote access blocked by a host?

This post is more than 2 years old.

Scott asks:

I am having an issue with hosting my CF8 application. I know your not in the hosting business but I'm wondering if you could offer some advise.

I have written this nice new applicaton that utilizes alot of the cool new CF8 ajax features, specifically the html CFGRID and CFAJAXPROXY (<--Coolest tag in the world by the way). The problem I'm having is I'm using a shared hosting environment. Since I'm on a shared server, I can not use remote functions for what I'm told are security reasons. I've read alot on these features and what I've found so far is that my functions has to be remote in order to bind them to a cfgrid or a cfajaxproxy.

Is there any way to get around having to have the functions that bind to cfgrid or cfajaxproxy be remote? Or is the only way I get to use these cool new features is to fork out the bucks for my own server? My own dedicated server is simply not in my budget at the time.

I had to reread this a few times. I've got a bad head cold and am still on my first cup of coffee, but this seems crazy. First off - as far as I know, there is no way to block remote access to a CFC at the server level. Just to be anal, you should confirm this. If you have a CFC named foo with remove method goo, open your browser to:

You should see a WDDX-encoded response. Again, as far as I know, no setting in the CF Admin lets you prevent remove CFC methods from firing. I'd love to know the name of this host because they obviously don't know what they are talking about. (And if I'm wrong, I'll blame the cold for being dumb. ;)

Now with that being said - one common problem people have with shared hosting and the new tags in CF8 is the availability of the CFIDE javascript files. All of the JavaScript necessary to run the new fancy Ajax crap is located uner /CFIDE. If your web site doesn't have access to /CFIDE, then your page will not work correctly. You can confirm this very quickly using Firebug. If so - just have your host add /CFIDE/scripts as a virtual folder to your web server and you should be fine.

Finally - yes - the Ajax features that integrate with CFCs must hit remote methods. Technically you can also hit CFMs instead, and have the CFMs run the CFC methods. That would let you use non-remote methods for the CFCs. It would also let you use Application-scoped CFCs for your Ajax calls.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by dc posted on 2/21/2008 at 5:27 PM

You can omit the need for a CFIDE mapping for the Ajax scripts by using the 'scriptsrc' attribute of cfajaxproxy to specify the location, and just upload all the necessary scripts from a Dev install of CF to your own web space.

Comment 2 by Raul Riera posted on 2/21/2008 at 5:38 PM

If indeed he is missing the CFIDE folder, an error will be displayed saying so (on JS happened to me a long while ago when I started making CF sites on shared hostings) I think his problem has to do with something else.

Perhaps he should look too see if he has the same problem as me before. Dont put your "proxy" CFC or any other remote access CFC inside a CFLOGIN restricted folder, or you wont be able to call those functions on Safari or FireFox (yup its bizzarre, but it does happens)

Comment 3 by Tony Garcia posted on 2/21/2008 at 6:41 PM

Another thing that has tripped me up when using cfajaxproxy was using the onRequest method in my Application.cfc. It's well-known that this breaks things like flash remoting and event gateway requests. But it also breaks remote calls to CFC's by cfajaxproxy. (and this isn't particular to shared servers)

Comment 4 by Brent posted on 2/21/2008 at 7:19 PM

@dc - That's not necessarily a best bet. Supposed Adobe releases a hot fix that changes some of those JavaScript files for some security reason. Then you're stuck with an old, and compromisable CFIDE folder. The best bet is to have the web host map the directory for you. I do it every day for our customers.

Comment 5 by Scott Reynolds posted on 2/22/2008 at 4:42 AM


Thanks for this. I will try out that test and let you know how it goes.

I have my CFIDE directory mapped so that's not my issue. I did have to special request that they map this for me though.

I'm not trying to bad mouth any hosts, I didn't know the answer either. What they told me specifically is that to call the remote function, ColdFusion's Remote Developer Services would need to be enabled. This is what they were not willing to do in their shared environment. If this is not the case, then whew..., I hope its just me.

Thanks again though. Your post has given me hope again. I'll let you know how it goes.


Comment 6 by Raymond Camden posted on 2/22/2008 at 7:05 PM

The only way the RDS comes into play is if you _view_ the CFC in your browser. To view auto-CFC documentation, you have to enter your CF Admin or RDS password. You aren't viewing the documentation though, nor do you need to. Your host is SERIOUSLY misinformed. While I don't want to bad mouth anyone, they really need to be 'schooled' on this.

Comment 7 by Scott posted on 2/26/2008 at 1:25 AM

I finally got this issue resolved. It turned out to be a Sandbox Security issue that was blocking access to my cfcs.

Lesson learned on all sides :). Thanks again for your help.