Web Development

• JSON Validation and Formatting in Gedit

  Dec 26, 2012

  Here are a couple of scripts for use with the External Tools plugin in Gedit that allow you to validate and format your JSON files using Python's json module. Simply copy each of these to ~/.config/gedit/tools, make sure they are executable, and then restart Gedit.

• Django 1.5, Python 3.3, and Virtual Environments

  Nov 11, 2012

  Today I wanted to tinker around with the experimental support for Python 3 in Django 1.5 (alpha). So, my first question was, how well does virtualenv play with Python 3? And that's when I learned about the new(ish) venv module available in Python 3.3.

• Django Contact Form with reCAPTCHA

  Oct 12, 2012

  The quix.django.contact app is a very basic contact form for Django 1.4. It simply allows users to send a message to email addresses specified in settings.py.

  This is how the quix.django.contact form can be extended with django-recaptcha to add a reCAPTCHA field to the form.

• Notes on Serving Django Apps with uWSGI

  Sep 27, 2012

  I've been playing around with deploying/migrating some Django projects to a Rackspace Cloud Server with Nginx and uWSGI. These are my notes on getting started with uWSGI.

  It should be noted that I am a developer and not a sys admin. Moreover, I am still learning and experimenting with uWSGI. This setup is being tested and tweaked on a few small projects that only handle a few thousand visitors per day. Rapid scalability and heavy loads are not a concern for these projects.

• Getting an IP Address in Django behind an Nginx Proxy

  Sep 24, 2012

  When running Django behind Nginx as a reverse proxy, the request.META['REMOTE_ADDR'] may store the proxy IP address (eg. 127.0.0.1) rather than the client's IP address. To get the client's IP address in Django, you can set the X-Forwarded-For HTTP header in your nginx proxy configuration:

  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  

  And then access it in Django with request.META['HTTP_X_FORWARDED_FOR']:

  ip = request.META['HTTP_X_FORWARDED_FOR']
  

  You would use request.META['HTTP_X_FORWARDED_FOR'] only when running Django behind a reverse proxy where you know that your server is setting the value and it is not being sent in the request. Therefore, getting the IP from request.META['HTTP_X_FORWARDED_FOR'] vs request.META['REMOTE_ADDR'] must be determined at the project-level and not within a reusable app.

  So, if you don't want your reusable apps using conditionals to determine where to get the IP address, what do you do? Well, I use a variation of the infamous SetRemoteAddrFromForwardedFor middleware. Once upon a time, Django shipped with this middleware to set the value of request.META['REMOTE_ADDR'] to request.META['HTTP_X_FORWARDED_FOR'] if it exists. It was removed in Django 1.2 as it was deemed too easy to be used incorrectly.

  I create XForwardedForMiddleware and put it into middleware.py at the project-level.

  class XForwardedForMiddleware():
      def process_request(self, request):
          if 'HTTP_X_FORWARDED_FOR' in request.META:
              request.META['REMOTE_ADDR'] = request.META['HTTP_X_FORWARDED_FOR']
          return None
  

  With this middleware installed, reusable apps can simply use request.META['REMOTE_ADDR'] and be blissfully unaware of the fact that it's behind a proxy.