Python Technology and Internet

Django Friday Tips: Security Checklist

Security is one of those areas where it is very hard to know if everything is taken care of. So you have been working on this project for a while and you want to deploy it into a production server, there are several settings on this new environment that should differ from your development one.

Since this is very common situation and there are many examples of misconfigurations that later turned to security issues, django has a security checklist (since version 1.8) to remind you of some basic aspects (mostly on/off switches) that you should make sure that are set correctly.

To run it on your project you simply have to execute the following command:

$python check --deploy

After the verification you will be presented with warnings like this one:

(security.W016) You have 'django.middleware.csrf.CsrfViewMiddleware' in your MIDDLEWARE_CLASSES, but you have not set CSRF_COOKIE_SECURE to True. Using a secure-only CSRF cookie makes it more difficult for network traffic sniffers to steal the CSRF token.

More information can be found in the documentation, since it uses the check framework, that has several interesting use cases.

Interested in more information about security in django? Check this video from the last edition of “Django Under the Hood“.


Django Friday Tips: Managing Dependencies

This one is not specific of django but it is very common during the development of any python project. Managing the contents of the requirements.txt file, that sometimes grows uncontrollably can be a mess. One of the root causes is the common work-flow of using virtualenv, install with pip all the required libraries and then do something like:

$pip freeze > requirements.txt

At the beginning this might work great, however soon you will need to change things and remove libraries. At this point, things start to get a little trickier, since you do not know which lines are a direct dependency of your project or if they were installed because a library you already removed needed them. This leads to some tedious work in order to maintain the dependency list clean.

To solve this problem we might use pip-tools, which will help you declare the dependencies in a simple way and automatically generate the final requirements.txt. As it is shown in the project readme, we can declare the following file:


Then we generate our “official” requirements.txt with the pip-compile command, that will product the following output:

# This file is autogenerated by pip-compile
# Make changes in, then run this to update:
#    pip-compile
amqp==1.4.8               # via kombu
anyjson==0.3.3            # via kombu
billiard==        # via celery
kombu==3.0.30             # via celery
pytz==2015.7              # via celery

Now you can keep track of where all those libraries came from. Need to add or remove packages? Just run pip-compile again.


Django friday tips: Switch the user model

In the most recent versions of django, you’re no longer attached to the default user model. So unlike what happened some time ago, when you had two models (User and Profile) “linked” together through an one-to-one relationship, nowadays you can extend or substitute the base user model.

It is as simples as adding the following line to your

AUTH_USER_MODEL = 'djangoapp.UserModel'

If you only want to extend it and avoid having to implement some boilerplate, you should sub class the AbstractUserModel like this:

from django.contrib.auth.models import AbstractUser

class User(AbstractUser):

This way you will be able to use all th predefined features, and even use the admin settings of the default user model by doing the following in your file:

from django.contrib.auth.admin import UserAdmin as DefaultUserAdmin

class UserAdmin(DefaultUserAdmin):

If you are starting out I hope this information was useful.