Snippets: Test Email Sending in Django

This is what I do when I want to test if sending of emails from a Django web app works.

First, in the project directory, I launched a manage shell session.

$ python shell

Then I entered the following commands.

Python 2.7.5 (default, Nov 20 2015, 02:00:19)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from django.core.mail.message import EmailMessage
>>> e = EmailMessage('S', 'M', '', [''])
>>> e.send()

A return of 1 means it’s working. A second later, the email came.

It works!

Notes: Install Python 2.7 on Cent OS 7 from Source

I enabled the EPEL repository.
Enable EPEL repository.

I upgraded setuptools.

$ sudo yum update python-setuptools

I installed python-pip.

$ sudo yum -y install python-pip

I installed pre-requisites.

$ yum groupinstall "Development tools"
$ yum install zlib-devel bzip2-devel openssl-devel ncurses-devel 
$ yum install sqlite-devel readline-devel tk-devel gdbm-devel 
$ yum install db4-devel libpcap-devel xz-devel

I could have actually issued the above yum install commands in one-line but..

I downloaded Python 2.7.10.

$ mkdir -p ~/Downloads
$ cd ~/Downloads
$ wget

I extracted the compressed file.

$ tar -xzf Python-2.7.10.tgz

I installed Python 2.7.10 from source.

$ cd Python-2.7.10
$ ./configure
$ make
$ sudo make altinstall

I created a symlink to Python 2.7 in /usr/local/bin which is on my PATH environment variable. (optional)

$ cd /usr/local/bin
$ sudo ln -s python2.7 python

It works!!

Django: Generic Class Based Views with Object Level Permissions Checking

A common design pattern in Django Class Based Views (CBVs) is checking whether the user is logged-in (authenticated) or not. If the user is authenticated, the view proceeds. If not, the view throws a permission denied exception. A common security feature in web sites.

For example, take a look at this code:

from django.contrib.auth.models import User
from django.db import models

class Blog(models.Model):
    title = models.CharField(max_length=255)
    user = models.ForeignKey(User)

from django.views.generic.edit import UpdateView

from models import Blog

class BlogUpdateView(UpdateView):
    model = Blog

from django.conf.urls.defaults import *
from django.contrib.auth.decorators import login_required

from views import BlogUpdateView

urlpatterns = patterns("views",

The is a common place to put these constraints. In here, only logged-in users are allowed to edit blog entries. Great!

But consider this scenario. Darwin logs-in, creates his blog, and then saves it. Mel happens to log-in, creates her blog, and saves it. Now two blog objects exist with IDs let’s say 1 for Darwin and 2 for Mel. Darwin tries to hack Mel’s blog and types the following address in his browser.

Remember that the codes above allow any logged-in user access to the view BlogUpdateView. Darwin could actually edit Mel’s blog entry and save his changes. Terrible!

Enter dslibpy.views.restricted

As a solution to the problem, I have rolled-out dslibpy.views.restricted. A set of “secure” Class Based Views that subclass each of the view classes in django.views.generic. I compiled the modules as part of a larger library of Python reusable codes. You can subclass these views in your projects to add restrictions to your views.

Here is the full documentation for dslibpy.views.restricted.

Installing dslibpy

dslibpy is absolutely free! You may use it, modify it, and redistribute it. The dslibpy documentation contains instructions on how to install dslibpy.


It worked!