Showing posts with label nginx. Show all posts
Showing posts with label nginx. Show all posts

Friday, September 4, 2009

RemoteObject Endpoints in Django

A few quick assumptions about your project:
  • It's built with a lightweight proxy server such as nginx or lighttpd
  • It utilizes the Django web framework
  • It remotes data using some form of ORM
  • It is presented via Flash/Flex
If this is the case, the simplest and most straightforward way to configure your gateway is by setting it at the root URL:

#my /etc/nginx/sites-enabled/mysite.conf
server {
listen 50.5.5.50:80;
server_name myurl.com www.myurl.com;
if ($host = 'www.myurl.com' ) {
rewrite ^/(.*)$ http://myurl.com/$1 permanent;
}

location / {
proxy_pass http://127.0.0.1:80/;
include /etc/nginx/proxy.conf;
}

location /media/ {
root /home/django/domains/myurl.com/public_html/;
}
}


Thus all web traffic that doesn't match '/media/' is passed to the urls.py for further processing. This is however at odds with your remoting requirements for Flash/Flex. To wit, you need a static file called crossdomain.xml to be available at your site's web root in order to meet the Flash client's security needs.

I looked for a good answer to this and found the Django-Flashpolicies by James Bennett effective and QUICK for this very purpose.

All you will need to do, essentially, is this:
easy_install django-flashpolicies

...and this...


url(r^'crossdomain.xml$',
'flashpolicies.views.simple',
{'domains': ['media.example.com', 'api.example.com']}),

...and you're good to go. Works better than a savage karate chop to the nose, most of the time anyway.

Hope that allows you to move forward quickly.

Thursday, September 3, 2009

Simple Endpoint Test for Asynchronous Unit and Integration Processes

In the creation of open-source RIAs, it can be very difficult to ensure connectivity of endpoints. There are potential snags and edge cases surrounding the following critical points:
  • Security clearance of port
  • Availability of port resource
  • Conflicts between multiple running servers
  • Properly-declared URI endpoints
As in point three, matters can be complicated when proxy servers, such as lighttpd or nginx are working in conjunction with apache. Most likely, both are open on different IP registers on port 80; apache proxy on localhost, and the lightweight server on the public IP.

An RIA will asynchronously connect via a RemoteObject call on another port. It requires a valid connection. Utilities like netcat can save you from a quagmire of ineffectual random testing.

First, open the port in apache, as it will be the ORM-enabled server. Typically, the port is 8000 or 8080 for arbitrary reasons of convention and familiarity. Make sure your 8000 or 8080 is not tied up with memchache or some other port-requisite ancillary utility. Open up ports.conf and add the port in the configuration script.

TEST THE PORT

Restart the apache server. Using a port utility such as netcat, test port connectivity. One quick way is to use netcat from a command line. Netcat will attempt to connect to any port(s) you specify and report the protocol it encountered:

nc -v -w 2 -z target 20-30

FIREWALLS

Don't forget to modify your security settings to allow the port! Specifically, if you have set up a firewall, iptables requires an entry allowing public connections over the port in question or connections will fail. If they have been changed, be sure to restart the apache server and that the rules have been saved either via command-line or the initializing script, usually /etc/network/interfaces.

Be sure your apache server's NameVirtualHost settings allow the wildcard * and not only localhost connections. This way, requests from your http-alt port will bypass your proxy server altogether. Apache might warn you thus, but it can be ignored:

[Thu Sep 03 16:20:42 2009] [warn] NameVirtualHost *:80 has no VirtualHosts

With these potential obstructions addressed, you should be able to tunnel your way to fame and fortune.

NEXT UP

How to put that port to use in an RIA RemoteObject call.