FeedMe!

Shortly after last week's Django 1.0.1 release, several people noted that the packaging script used to produce the release omitted several directories from the Django source tree; mostly this affected some unit tests, but at least one of the omitted directories affected the use of Django itself (specifically, of django.contrib.gis). So tonight we're issuing Django 1.0.2, which is built around an updated packaging script and should resolve these problems.

This is a recommended upgrade for anyone using or targeting Django 1.0 or Django 1.0.1; to obtain a copy, swing by the downloads page, and don't forget to read the release notes. For the security conscious, a signed file containing the package's checksums is, as always, available.

There is a bug in all 2.1.x versions of Ruby on Rails which affects the effectiveness of the CSRF protection given by protect_from_forgery.

By design rails does not perform token verification on requests with certain content types not typically generated by browsers. Unfortunately this list also included ‘text/plain’ which can be generated by browsers.

Impact

Requests can be crafted which will circumvent the CSRF protection entirely. Rails does not parse the parameters provided with these requests, but that may not be enough to protect your application.

Affected Versions

• All releases in the 2.1 series
• All 2.2 Pre Releases

Fixes

The upcoming 2.1.3 and 2.2.2 releases will contain a fix for this issue.

Interim Workarounds

Users of 2.1.x releases are advised to insert the following code into a file in config/initializers/

Mime::Type.unverifiable_types.delete(:text)

Users of Edge Rails after 2.2.1, should upgrade to the latest code in 2-2-stable.

The patch for the 2.1.x series is available on github. This will also apply cleanly to 2.2 pre-releases prior to this changeset released on Thursday November 13th at 11:19:53 2008 CET. Users with edge-rails checkouts after that date, are advised to upgrade to the latest code in 2-2-stable.

Thanks to Steve from Coderrr for reporting this issue.

There is a bug in all 2.1.x versions of Ruby on Rails which affects the effectiveness of the CSRF protection given by protect_from_forgery.

By design rails does not perform token verification on requests with certain content types not typically generated by browsers. Unfortunately this list also included ‘text/plain’ which can be generated by browsers.

Impact

Requests can be crafted which will circumvent the CSRF protection entirely. Rails does not parse the parameters provided with these requests, but that may not be enough to protect your application.

Affected Versions

• All releases in the 2.1 series
• All 2.2 Pre Releases

Fixes

The upcoming 2.1.3 and 2.2.2 releases will contain a fix for this issue.

Interim Workarounds

Users of 2.1.x releases are advised to insert the following code into a file in config/initializers/

Mime::Type.unverifiable_types.delete(:text)

Users of Edge Rails after 2.2.1, should upgrade to the latest code in 2-2-stable.

The patch for the 2.1.x series is available on github. This will also apply cleanly to 2.2 pre-releases prior to this changeset released on Thursday November 13th at 11:19:53 2008 CET. Users with edge-rails checkouts after that date, are advised to upgrade to the latest code in 2-2-stable.

I just reduced the housework needed to setup a new Rails application with i18n. All new applications will ship with a config/locales directory that’s automatically wired up in the load path for i18n. So you can just drop .yml or .rb locale files in there and they’ll be instantly available for translation.

There’s also a sample config/locales/en.yml file in there to give you a starting point. In addition, the initializer is now wired up through the Rails config. The new default environment.rb provides these pointers:

# The internationalization framework can be changed 
# to have another default locale (standard is :en) or more load paths.
# All files from config/locales/*.rb,yml are added automatically.
# config.i18n.load_path << Dir[File.join(RAILS_ROOT, 'my', 'locales', '*.{rb,yml}')]
# config.i18n.default_locale = :de

So on a fresh Rails 2.2 application, you’ll be able to do see it all wired up out of the box (the :hello key is from the config/locales/en.yml demo file):

$ ./script/console
>> I18n.t :hello
=> "Hello world"

Rails 2.2 final is just around the corner. We’ve been ironing out the last bugs and added the last amount of polish to make this a kick ass release. Also, work on 2.3 / 3.0 has already begun in master as well since we’ve branched for 2.2 a while back.

I just reduced the housework needed to setup a new Rails application with i18n. All new applications will ship with a config/locales directory that’s automatically wired up in the load path for i18n. So you can just drop .yml or .rb locale files in there and they’ll be instantly available for translation.

There’s also a sample config/locales/en.yml file in there to give you a starting point. In addition, the initializer is now wired up through the Rails config. The new default environment.rb provides these pointers:

# The internationalization framework can be changed 
# to have another default locale (standard is :en) or more load paths.
# All files from config/locales/*.rb,yml are added automatically.
# config.i18n.load_path << Dir[File.join(RAILS_ROOT, 'my', 'locales', '*.{rb,yml}')]
# config.i18n.default_locale = :de

So on a fresh Rails 2.2 application, you’ll be able to do see it all wired up out of the box (the :hello key is from the config/locales/en.yml demo file):

$ ./script/console
>> I18n.t :hello
=> "Hello world"

Rails 2.2 final is just around the corner. We’ve been ironing out the last bugs and added the last amount of polish to make this a kick ass release. Also, work on 2.3 / 3.0 has already begun in master as well since we’ve branched for 2.2 a while back.

I've seen a lot of discussion lately about different strategies for developing and deploying Django applications. I wanted to share my current environment in the hopes that it might help someone new to Django or software development in general, and I was also hoping for some constructive criticism so that I can learn best practices. Most of my coding is done on my own, but I've been trying to stay away from cowboy coding habits as much as possible to keep my development practices disciplined.

I started out using Gedit with plugins and the Linux command shell, and that worked very well. As my projects grew larger, though, I really wanted a more feature-rich environment that would allow tighter integration of Subversion. I also did a small amount of development on a Windows machine (not by choice), and I wanted a development environment that I could use across multiple platforms. I settled on Eclipse after a lot of experimentation, and so far I've really enjoyed it.

My Development Environment

To start out with, I'll talk a little about my development environment. I use an Ubuntu laptop and desktop for development, switching back and forth depending on how I feel at the moment. The desktop is custom-built, and the laptop is from HP. They are both dual-core amd64 machines, and I've been very happy with how Linux support for the amd64 architecture has progressed.

I use the Eclipse Ganymede classic download with the Aptana, PyDev, and Subclipse plugins. The reason I use the classic download instead of the standalone Aptana Studio is twofold, actually. First, there's no amd64 version of the standalone Aptana download yet. Secondly, on the Windows machine I've noticed better compatibility with Eclipse classic for some of the other minor plugins I've tried out. I believe Aptana's standalone software is currently running Eclipse 3.2, and a few of the plugins I tried needed 3.3 or better.

For version control, I use Subversion. I host my own subversion server on my testing machine, which I'll talk more about in a moment. I organize my repository with the customary trunk, branches, and tags folder in the root of the repository. Under branches, I keep a separate testing branch and production branch for those environments. For each project in my repository, I have a directory underneath trunk. In each project directory, I have a templates and static directory. When I want to test or deploy changes, I merge the revisions I want from trunk to one of my branches.

Under the home directory on my development machines, I have a full checkout from SVN including all the branches. Then, using symlinks I mirror the directory layout that my production host, WebFaction, uses. For this layout, I have a top-level webapps directory. Underneath that I have a django directory which I add to my PYTHONPATH, and a static directory to house symlinks to each project's static content. I do this so that each site also has access to “shared” static content including common JS files, a reset stylesheet, etc. In my templates, “/static/project/” points to the project-specific files and “/static/shared/” points to the shared media.

In the django directory, I symlink all of my project directories from my SVN checkout, including a project I call plugins which includes svn:externals links to several third-party apps. I also include Django itself as an external there.

When I develop, I always svn update first to syncronize my checkout, and then I use the built-in Django development server. I have PostgreSQL installed on each development machine, and I use pg_dump dbname > dump.sql from the production server and then psql dbname < dump.sql on the development machine when I need a fresh copy of the database for an existing site.

My Testing Environment

For testing, I use a separate custom Ubuntu machine running a single-core 32-bit AMD processor. In my home directory I have just the testing branch checked out, and again I mirror my production environment through symlinks. The SVN repository is hosted on this machine, and I will soon be implementing periodic backups. I also host Trac from this machine for project management. To reach the machine remotely, I've set up DNS overrides with my production host. I'm planning on a cron script that will update the IP address periodically with WebFaction since my IP address changes every time I lose my connection to my ISP (mainly due to infrequent power outages).

I run PostgreSQL for the database and Apache for the webserver, using mod_python for interaction with Django. I have a VirtualHost set up for testing, and I add each site as a Location under that VirtualHost. That way each testing site sits under the testing domain as a root directory, such as http://testing.server.com/myproject/ and http://testing.server.com/myotherproject/.

My Production Environment

For production, as I mentioned before, I use WebFaction. It allows Linux shell access through SSH, and they have a helpful library of knowledge-base entries and forum posts that have really made them easy to use. I have a checkout of just the production branch under my home directory, and then I use symlinks within their directory structure to set up the environment.

In the panel, I have a django application installed and a static application installed, which adds those directories under the webapps directory. The django directory also includes the Apache configuration files and a Python site-packages directory. From the site-packages directory, I've removed django and use the svn:external for Django from my plugins project. I have each separate site set up as a VirtualHost entry in the Apache conf.

When I am ready to make changes in the production environment, I'll merge them to the production branch on my development machine and make sure there are no conflicts. My production branch already has the production settings (such as DEBUG = False) and my merges don't change that. Once I resolve any conflicts, I commit the production branch and then SSH into the production server to do an svn update under the checkout directory. I run python2.5 manage.py syncdb and whatever else I need to do in the command line under my project, and then restart the Apache server. From there, I fire up Firefox and check to see if everything worked.

So far this setup has served me well, but I'm very open to suggestions or questions. Please feel free to post comments to discuss.

I find economics to be a fairly interesting subject, mind you I'm bored out of my mind about hearing about the stock markets, derivatives, and whatever else is on CNBC, but I find what guys like Steven Levitt and Steve E. Landsburg do to be fascinating. A lot of what they write about is why people do what they do, and how to incentivise people to do the right thing. Yesterday I was reading through David Goodger's Code Like a Pythonista when I got to this portion:

LUKE: Is from module import * better than explicit imports?

YODA: No, not better. Quicker, easier, more seductive.

LUKE: But how will I know why explicit imports are better than the wild-card form?

YODA: Know you will when your code you try to read six months from now.

And I realized that Python had learned a lot from these economists.

It's often dificult for a programmer to see the advantage of doing something the right way, which will be benneficial in six months, over just getting something done now. However, Python enforces doing things the right way, and when doing things the right way is just as easy as doing in the wrong way, you make the intuitive decision of doing things the right way. Almost every code base I've worked with(outside of Python) had some basic indentation rules that the code observed, Python just encodes this into the language, which requires all code to have a certain level of readability.

Django has also learned this lesson. For example, the template language flat out prevents you from putting your business logic inside of it without doing some real work, you don't want to do that work, so you do things the right way and put your business logic in your views. Another example would be database queries, in Django it would be harder to write a query that injected unescaped into your SQL than it would be do the right thing at use parameterized queries.

Ultimately, this is why I like Python. The belief that best practices shouldn't be optional, and that they shouldn't be difficult creates a community where you actively want to go and learn from people's code. Newcomers to the language aren't encouraged to "just get something working, and then clean it up later," the communiity encourages them to do it right in the first place, and save themselves the time later.

Django comes with a useful sessions framework which allows you to implement persistence during a single ‘session’ of interaction between a user and your site. Aside from storing things like preferences, this allows you to implement “wizards” (forms split across multiple pages), history and memory (i.e. for pagination) across a short period of time. A session is essentially a dictionary, available in the request object’s session attribute, which you can set and retrieve keys on. I don’t really need to explain it, because Django’s documentation on sessions is perfect, thank you very much.

One feature of sessions, however, is not very well publicized. The sessions framework supports an additional setting (in settings.py, of course) called SESSION_ENGINE. Usually, you see, the sessions are stored in your main database, in a special table for the purpose. However, if you heavily rely on sessions in your views, this will incur a large cost to the database; each page will have an additional read and an additional write. If your database is the kind that likes to explode in your face occasionally, that’s not really cool.

In fact, I probably definitely don’t need to explain how reducing database hits is a good thing.

So what can be done about this problem? Well, two years ago, ticket #2066 came along, asking for pluggable session backends. About a year later it was closed, and the option to change the session backend was added to Django. You can now choose to use different backends instead of the usual database method.

To exploit this functionality, simply add SESSION_ENGINE to your settings.py, and set it to “django.contrib.sessions.backends.cache”. This will cause sessions to be stored in your configured cache backend, which (usually) will be memcached. If, however, you don’t have a memcached instance up and running, you can get it going relatively easily; search the Django docs for how to set up a cache (hint: it’s SUPER-easy).

That’s the end of this unnecessarily long blog post on an über-simple feature of Django. If I’d written all the Django docs, they’d have to be shipped on DVDs.

As a point of historical note, the sites that caused Django to be created, LJWorld, Lawrence.com and KUSports.com have all launched on Ellington running on Django 1.0! It's been a long process to get here, and we have a little ways to go yet, but this is a very satisfying moment.