CURRENT PROJECTS
loading
CATEGORIES AND POSTS
loading
overset
DEVELOPMENT LOG FOR JIM PALMER
Posted 07/13/2007 in unix


I must disclaim that this is a very straight forward proxy example yet it does not work with AJAX and web browser's cross-domain security policies/complexes. There is actually a far more elegant solution I use currently which enables complete support for Flash Remoting and AJAX calls to be made via a cluster of proxies even within a cluster of web servers. That writeup is here.

Every other developer trying to harness the power of Flash Remoting has to deal with the stringent cross-domain security complex that Macrodobe subscribes to. The simple fix I offer here is just a proxy through the same server that serves the initial SWF file to different network-accessible server via IPTABLES proxy.

I show a couple simple IPTABLES rules here that can be run on any newer stock Linux box to offer a way to "cheat" the Flash Remoting security complex through proxy. Albeit any proxy solution is not quite a cheat and is truly an elegant solution because it will always be within a controlled environment.

I'll try to outline the case here a bit more. We have an Apache server that serves the initial SWF file from a specific domain/HOST. Flash Remoting's forces any communication back only through the same protocol:domain combination. In our case we're hosting the SWF via https://www.vanity.domain/super.swf which means we can only make flash remoting calls via the same HTTPS protocol and www.vanity.domain host. What you can do is make flash remoting calls through the same protocol:domain pair and a different port (IMPORTANT TO NOTE: You can't do this through AJAX or the web browser's XMLHttpRequest() - This is where Flash Remoting and Ajax somewhat differ). So there is our goal, to be able to send all the Remoting requests through a different port, i.e. port 8100. In sum the SWF will be served via https://www.vanity.domain:80/super.swf and the Flash Remoting calls will be directed to https://www.vanity.domain:8100/GATEWAY.

On to setting up the kernel-level transparent proxy. What we harness here is setting up a TCP and UDP POSTROUTING and PREROUTING set of rules for specific network traffic. Say our www.vanity.domain resolved to 192.168.10.10 and the "remote" server that we want to proxy our Flash Remoting calls to resides at 10.0.0.20 the rules would simply be:
# iptables -t nat -I PREROUTING -d 192.168.10.10 -p tcp --dport 8100 -j DNAT --to 10.0.0.20:443
# iptables -t nat -I PREROUTING -d 192.168.10.10 -p udp --dport 8100 -j DNAT --to 10.0.0.20:443
# iptables -t nat -I POSTROUTING -d 10.0.0.20 -p tcp --dport 443 -j SNAT --to 192.168.10.10
# iptables -t nat -I POSTROUTING -d 10.0.0.20 -p udp --dport 443 -j SNAT --to 192.168.10.10

You can review you newly created rules via:
iptables -L PREROUTING -t nat
iptables -L POSTROUTING -t nat

or to view the complete "NAT" routing map:
iptables -L -t nat

It would be advised to set these up within an init script so that the rules would hold upon any number of reboots. It's also strongly advised to become as informed as much as possible on the iptables functionality and features. The DNAT and SNAT are horribly useful for such proxies and understanding how to "manage" your rules. They're simple, straightforward and VERY powerful.
comments
loading
new comment
NAME
EMAIL ME ON UPDATES
EMAIL (hidden)
URL
MESSAGE TAGS ALLOWED: <code> <a> <pre class="code [tab4|tabX|inline|bash]"> <br>
PREVIEW COMMENT
TURING TEST
gravatar