Seeing as XMLHTTPRequest.open() is limited to only working on URI's on the same domain:port pair as the page was originally loaded from - I had a problem trying to access an AJAX handler on a different host.
I solved this problem with Apache's mod_proxy. This caused another issue with the client authentication functionality in CFAJAX.
First off, to enable the utilization of authentication of each incoming CFAJAX request, add the following hint declaration to each function you wish to make sure is authenticated.
It is important to note that this is different than the sessioncheckfunction hint declaration.
The problem is that the decodeClientAuthenticationKey function in the security.cfm file will only return true if the CGI.REMOTE_ADDR is the same as what was originally encoded. In the case of using a web proxy to access you AJAX handler - the CGI.REMOTE_ADDR will be the address of the proxy machine instead of the address of the client's machine in which the authentication was initially Encrypt()ed. The solution is to pass the end-user's IP address through the proxy in the form of a URL variable.
I decided that (after trying Solution #2 below) there was no way to verify each incoming request from a client's browser beyond just enabling strong asymmetrical encryption as CFAJAX already supports. This means removing all of CFAJAX's IP verification in the client key authentication. I simply commented out the IPVERIFIED==true cfif in the cfajax.cfm's authenticateClient hint "function". I wanted to retain the TIMEELAPSED condition.
There is no need, in our case, to impossibly authenticate the client's IP address (because of masquerading issues) to verify incoming requests. I see utilizing the client authentication more as preventing a completely open door to potential malicious attacks. The grunt of the logic and dangerous database changes will occur only if a valid session exists - hence more importance on using sessioncheckfunction.
WARNING - This will NOT work when the client is accessing AJAX calls from behind a bridge/maquerading box. I.e. a great majority of end-users on the net.
To accomplish passing of the end-user's IP through the proxy I setup a QSA, Query String Append, variable at the end of my proxy Rewrite Rule as follows:
The RewriteRule will choose a specific proxy cluster member as declared in the declaration. This is part of the Apache 2.2.X mod_proxy_balancer module. The [P] declaration takes advantage of the mod_proxy module in Apache. The [QSA] declaration enables graceful query string appending. Case in point, if the original address for the VirtualHost declaration was http://10.0.0.1 here are two test queries and how they would be proxied: