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 manage.py 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.
(InteractiveConsole)
>>> from django.core.mail.message import EmailMessage
>>> e = EmailMessage('S', 'M', 'noreply@domain.com', ['dar@domain.com'])
>>> e.send()
1
>>>

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

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:

models.py

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)
    #..one-million-lines-of-code-here..

views.py

from django.views.generic.edit import UpdateView

from models import Blog

class BlogUpdateView(UpdateView):
    model = Blog
    #..one-million-lines-of-code-here..

urls.py

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

from views import BlogUpdateView

urlpatterns = patterns("views",
    url(r"^blogs/update/(?P<pk>\d+)/$",
        login_required(BlogUpdateView.as_view()),
        name="update_blog"),
)

The urls.py 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.

http://my.blogsite.net/blogs/update/2

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.



References

It worked!