Michael Herman has been teaching and writing Django, Python, JavaScript and more

for years. We’ve always found his works enlightening and useful.

Timeless Beginner Django Material

Web:

Official Django 3.0 Documentation

docs.djangoproject.com/en/3.2/
The official Django documentation is incredibly useful. If you’ve used a previous ver-
sion of Django, make sure that you are reading the correct edition of the documenta-
tion.
Django Girls Tutorial
tutorial.djangogirls.org
Created and maintained by the international Django Girls organization, this is an
excellent resource no matter your gender.
Simple is Better than Complex simpleisbetterthancomplex.com/
Vitor Freitas’ beginner level material is very well written.

Timeless Beginner Python Material

Learn Python the Hard Way Online Edition
learnpythonthehardway.org
By going right to the source, this free for HTML, paid for video resources, is one of
the best places to start. The video resources are especially useful.
Automate the Boring Stuff with Python
amazon.com/gp/product/1593275994
This fascinating book teaches Python by instructing on how to make boring com-
puter tasks easy through automation. Why update 150 columns of a spreadsheet when
Python can do it for you?

Timeless Useful Python Material

Fluent Python
amzn.to/2oHTORa
One of our favorite Python books, author Luciano Ramalho tours Python’s core lan-
guage features and libraries, and shows us how to make code shorter, faster, and more
readable at the same time.
Effective Python
amzn.to/1NsiqVr
Instructs on many useful practices and techniques when coding in Python.
Python Cookbook, 3rd Edition
amzn.to/I3Sv6q
Appendix C: Additional Resources

An incredible book by Python luminaries David Beazley and Brian Jones, it’s filled
with delicious ice cream recipes... err... incredibly useful Python recipes for any devel-
oper using Python 3.3 or greater.
Treading on Python Volume 2
amzn.to/1kVWi2a
Covers more advanced Python structures.
Writing Idiomatic Python 3.3
amzn.to/1aS5df4
Great tips for optimizing your code and increasing the legibility of your work. There
are a few places it differs from our practices (imports being the largest area of differ-
ence), but overall we concur. A 2.7 version is available at amzn.to/1fj9j7z

JavaScript Resources
WARNING: ATTENTION: Help Wanted!

Books:

Secrets of a JavaScript Ninja (Print and Kindle)

amzn.to/2AknxYp
TODO - Add more good, modern JS books!

Web Resources:

Mozilla Developer Network

developer.mozilla.org/en-US/docs/Web/JavaScript
Stack Overflow
stackoverflow.com/questions/tagged/javascript
TODO - Add at least one more good, modern JS web resource!

WARNING: Stay Away From W3Schools

One problem about JavaScript (and CSS) research on the web is that W3Schools
will turn up at the top of search engine results. This is unfortunate, because much of
the data there is outdated enough to be incorrect. Be smart and avoid this resource.

We scan the results page for the Mozilla Developer Network (MDN) link, usually
around the third position, and click on that one.
Appendix D: Internationalization and
Localization

Django and Python provides a lot of very useful tools for dealing with internationalization,
localization, and Unicode.

This appendix contains a list of things helpful for preparing your Django application for
non-English readers and non-USA users. This list is by no means complete, and we invite
the reader to provide additional feedback.

Start Early
It is always easier to start with and grow an internationalized, localized project than to
convert an existing project.

Wrap Content Strings with Translation Functions

Every string presented to end users should be wrapped in a translation function. This is de-
scribed in-depth in the official Django documentation on django.utils.translation
at docs.djangoproject.com/en/3.2/topics/i18n/translation/. Since that is a
lot of text to swallow, the table on the following page is a reference guide for knowing when
and where to use what translation function for what tasks.
Appendix D: Internationalization and Localization

Function Purpose Link

gettext() For content executed at docs.djangoproject.
runtime, e.g. form valida- com/en/3.2/topics/
tion errors. i18n/translation/
#standard-translation
gettext_lazy() For content executed docs.djangoproject.
at compile time, e.g. com/en/3.2/topics/
verbose_name in mod- i18n/translation/
els. #lazy-translation
Replaces the standard
django.utils.text.format_lazy() docs.djangoproject.
str.join() method for com/en/3.2/topics/
joining strings. i18n/translation/
#formatting-strings-format-lazy

Table 1: Translation Function Reference

Convention: Use the Underscore Alias to Save Typing

As you know, normally we aren’t fans of abbreviations or shortcuts. However, in the case of
internationalizing Python code, the existing convention is to use a _, or underscore, to save
on letters.

Example 9: The Underscore Alias in Action

from django.utils.translation import gettext as _

print(_('We like gelato.'))

Don’t Interpolate Words in Sentences

The golden rule is always have as much grammar as possible in the string, don’t
let the code piece the grammar together; and generally verbs are the most prob-
lematic.

– Patrick McLoughlan

We used to construct translation strings all the time, going so far as to include it in the 1.5
edition of the book. This is when you use slightly-clever code to construct sentences out of
various Python objects. For reference, this was part of Example 8.7:

Example 10: Our Bad Code from the 1.5 Edition

# DON'T DO THIS!
 # Skipping the rest of imports for the sake of brevity
class FlavorActionMixin:

@property
def action(self):
msg = '{0} is missing action.'.format(self.__class__)
raise NotImplementedError(msg)

def form_valid(self, form):

msg = 'Flavor {0}!'.format(self.action)
messages.info(self.request, msg)
return super().form_valid(form)

# Snipping the rest of this module for the sake of brevity

While seemingly handy in that it makes for a self-maintaining mixin, it is overly clever in
we can’t internationalize the result of calling self.__class__. In other words, you can’t
just add django.utils.translation the following and expect it to produce anything
meaningful for translators to work from:

Example 11: Making Things Impossible For Translators

# DON'T DO THIS!
from django.utils.translations import gettext as _

# Skipping the rest of this module for the sake of brevity

def form_valid(self, form):

# This generates a useless translation object.

msg = _('Flavor {0}!'.format(self.action))
messages.info(self.request, msg)
return super().form_valid(form)

# Skipping the rest of this module for the sake of brevity

Rather than writing code that constructs sentences out of various Python constructs, now
we write more meaningful dialogues that can be readily translated. This means a little more
work, but the result is a more easily translatable project. Hence we now follow this pattern:
Appendix D: Internationalization and Localization

Example 12: Use of Complete Strings

# Skipping the rest of imports for the sake of brevity

from django.utils.translation import gettext as _

class FlavorActionMixin:

@property
def success_msg(self):
return NotImplemented

class FlavorCreateView(LoginRequiredMixin, FlavorActionMixin,

CreateView):
model = Flavor

# Slightly longer but more meaningful dialogue

success_msg = _('Flavor created!')

# Skipping the rest of this module for the sake of brevity

For reference, you can combine individual strings representing meaningful sentences and
dialogues into larger values. However, you shouldn’t build sentences by concatenating pieces,
because other languages may require a different order. For the same reason, you should
always include punctuation in translated strings. See as follows:

Example 13: Using Punctuation in Translated Strings

from django.utils.translation import gettext as _

class FlavorActionMixin:

@property
def success_msg(self):
return NotImplemented

class FlavorCreateView(LoginRequiredMixin, FlavorActionMixin,

CreateView):
model = Flavor

# Example combining strings

part_one = _('Flavor created! ')
 part_two = _("Let's go try it!")
success_msg = part_one + part_two

# Skipping the rest of this module for the sake of brevity

Unicode Tricks
Here are some things we’ve learned when dealing with unicode-related issues.

Use django.utils.encoding.force_text() Instead of str()

When we need to ensure that a useful string-type value is returned, don’t use the str()
built-in. What can happen is that under certain circumstances, instead of returning a ustr
object, Django will return a nigh-meaningless django.utils.functional.__proxy__
object, which is a lazy instance of the data requested.

Instead, do as our friend Douglas Miranda suggested to us, and use

django.utils.encoding.force_text. In the case that you are dealing with a proxy
object or lazy instance, it resolves them as strings.

TIP: Django is Lazy

One of the ways that Django does optimizations is via lazy loading, a design pat-
tern which defers initialization of an object until it is needed. The place where
this is most used is Django’s ORM, as described at docs.djangoproject.
com/en/3.2/topics/db/queries/#querysets-are-lazy. This use of lazy
objects can cause problems with display of content, hence the need for
django.utils.encoding.force_text().

Browser Page Layout

Assuming you’ve got your content and Django templates internationalized and localized,
you can discover that your layouts are broken.

A good Django-based example is Mozilla and their various sites for supporting tools like
Firefox. On these sites they handle translations for over 80 languages. Unfortunately, a title
that fits the page in English breaks the site in more verbose languages such as German.

Mozilla’s answer is to determine the width of a title container, then use JavaScript to adjust
the font size of the title text downwards until the text fits into the container with wrapping.

A simpler way of handling this issue is to assume that other languages can take up twice as
Appendix D: Internationalization and Localization

much space as English. English is a pretty concise language that, because of its short words,
handles text wrapping very well.

The Challenges of Time

Time is a tricky subject even without timezones and different calendering systems. Here are
resources to help navigate through time-based coding:

ä yourcalendricalfallacyis.com
Appendix E: Settings Alternatives

Here a couple of alternative patterns for managing settings that we feel can be recommended.
They avoid the local_settings anti-pattern and allow for management of configuration that
will work with either the Environment Variables Pattern or the Secrets File Pattern.

WARNING: Converting Existing Settings is Hard

If you have an existing project using multiple settings modules and you want to con-
vert it to the single settings style, you might want to reconsider. Migrating settings
approaches is always a tricky process, and requires deep and wide test coverage. Even
with the best test coverage, there is a chance it’s not going to be worth it.

For these reasons, we suggest being conservative about switching to new settings
approaches. Only do it when the current settings management approach has become
a pain point, not when a new method becomes popular.

Twelve Factor-Style Settings

If we’re relying on environment variables, why not use the simplest settings.py system pos-
sible? Bruno Renié, creator of django-floppyforms and FeedHQ (feedhq.org), advocates
an alternate approach to Django settings files, in which all environments use the same single
settings file.

The argument for this approach is that when using the multiple settings files approach,
you end up with environment-specific code. For instance, when doing local development,
you’re not running the code with production settings. This increases the chance of running
into production-specific bugs when you update some code without updating the production
settings accordingly.

This style involves using sensible default settings and as few environment specific values as
possible. When combined with tools like Vagrant and Docker, it means that mirroring
production is trivial.
Appendix E: Settings Alternatives

It results in a much simpler settings file, and for Twelve Factor App fans, it’s right in line
with that approach.

If you want to see an example of the approach in action, check out FeedHQ’s settings mod-
ule: github.com/feedhq/feedhq/blob/master/feedhq/settings.py

We’ve enjoyed this approach for new and smaller projects. When done right, it makes things
elegantly simple.

However, it’s not a perfect solution for all problems:

ä It doesn’t provide much benefit for simplification when development environments

are drastically different than production.
ä It doesn’t work as well with projects being deployed to more than one operating sys-
tem.
ä Complex settings on large projects are not really simplified or shortened by this ap-
proach. It can be challenging to use on large or complex projects.

If you would like to know more about this approach, we recommend the following articles:

ä bruno.im/2013/may/18/django-stop-writing-settings-files/
ä 12factor.net/config
Appendix G: Security
Settings Reference

In Django, knowing which setting should be set to what value in development vs production
requires an unfortunate amount of domain knowledge. This appendix is a reference for better
understanding how to configure a Django project for both development and production.

Setting Development Production

ALLOWED_HOSTS any list See ??
Cross Site Request Forgery See next page See next page
protection
DEBUG True False
False
DEBUG_PROPAGATE_EXCEPTIONS False
Email SSL See next page See next page
MIDDLEWARE_CLASSES Standard Add
SecurityMiddleware
SECRET_KEY Use cryptographic key See section 5.3
True
SECURE_CONTENT_TYPE_NOSNIFF True
SECURE_PROXY_SSL_HEADERNone See next page
SECURE_SSL_HOST False True
SESSION_COOKIE_SECURE False True
SESSION_SERIALIZER See below See next page

Table 2: Security Settings Reference

Cross Site Request Forgery Protection Settings

For most cases, the standard Django defaults for these settings are adequate. This list pro-
vides references to edge cases and the CSRF setting documentation that might provide
mitigation:

ä Internet Explorer and CSRF failure: docs.djangoproject.com/en/3.2/ref/

settings/#csrf-cookie-age
ä Cross-subdomain request exclusion, (e.g. posting from
Appendix F: Security Settings Reference

vanilla.twoscoopspress.com to chocolate.twoscoopspress.com):
docs.djangoproject.com/en/3.2/ref/settings/#csrf-cookie-domain
ä Changing the default CSRF failure view: docs.djangoproject.com/en/3.2/
ref/settings/#csrf-failure-view

Email SSL
Django supports secure connections to SMTP servers. We strongly suggest using this fea-
ture. Documentation on the following settings begins at docs.djangoproject.com/en/
3.2/ref/settings/#email-use-tls

ä EMAIL_USE_TLS
ä EMAIL_USE_SSL
ä EMAIL_SSL_CERTFILE
ä EMAIL_SSL_KEYFILE

SESSION_SERIALIZER
Per subsection 28.10.4:

SESSION_SERIALIZER = django.contrib.sessions.serializers.JSONSerializer.

SECURE_PROXY_SSL_HEADER
For some setups, most notably Heroku, this should be:

SECURE_PROXY_SSL_HEADER = (`HTTP_X_FORWARDED_PROTO', `https')

Appendix G: Handling Security Failures

Have a Plan Ready for When Things Go Wrong

Handling security failures is incredibly stressful. There is a sense of urgency and panic that
can overwhelm our better judgement, leading to snap decisions that can involve ill-advised
‘bug fixes’ and public statements that worsen the problem.

Therefore, it’s critical that a point-by-point plan be written and made available to maintain-
ers and even non-technical participants of a project. Here is a sample plan:

1 Shut everything down or put it in read-only mode.

2 Put up a static HTML page.
3 Back everything up.
4 After reading docs.djangoproject.com/en/dev/internals/security/,
email security@djangoproject.com about your security-related problem, even if it’s
your fault.
5 Start looking into the problem.

Let’s go over these steps:

Shut Everything Down or Put It in Read-Only Mode

The first thing to do is remove the ability for the security problem to continue. That way,
further damage is hopefully prevented.

On Heroku:

Example 14: Turning on Maintenance Mode for Heroku Projects

\$ heroku maintenance:on
Enabling maintenance mode for myapp... done
Appendix G: Handling Security Failures

For projects you deploy yourself or with automated tools, you’re going to have create this
capability yourself. Fortunately, other people have faced this before so we come prepared
with reference material:

ä cyberciti.biz/faq/custom-nginx-maintenance-page-with-http503
for putting up maintenance 503 pages.
ä Other tools can be found at djangopackages.org/grids/g/
emergency-management

Put Up a Static HTML Page

You should have a maintenance page formatted and ready to go when you launch your
project. This way, when things go wrong and you’ve shut everything down, you can display
that to the end user. If done well, the users might understand and give you the breathing
room to work out the problem.

Back Everything Up
Get a copy of the code and then the data off the servers and keep it on a local hard drive or
SSD. You might also consider a bonded, professional storage company.

Why? First, when you back things up at this stage, you are protecting your audit trail. This
might provide you with the capability to determine where and when things went wrong.

Second, and this might be unpleasant to hear, but malignant staff can cause as many prob-
lems as any bug or successful penetration. What that means is that the best software-based
security is useless against a developer who creates a backdoor or a non-technical staff level
user who decides to cause trouble.

Email security@djangoproject.com, Even if It’s Your Fault

As long as your problem is security related, read through docs.djangoproject.com/en/
dev/internals/security/, then send a quick email summarizing the problem. Ask for
help while you are at it.

There are a number of reasons why this is important:

ä Writing up a quick summary will help you focus and gather your thoughts. You’re
going to be under an amazing amount of stress. The stress and urgency of the situation
can make you attempt stupid things that can aggravate the problem.
ä You never know, the Django security team might have good advice or even an answer
for you.
ä It might be a Django problem! If that is the case, the Django security team needs to
know so they can mitigate the problem for everyone else before it becomes public.
 TIP: Jacob Kaplan-Moss on Reporting to the Django Project
Former Django BDFL and former Director of Security for Heroku Jacob Kaplan-
Moss says, “I’d much rather have people send things that aren’t actual problems
in Django to security@djangoproject.com than accidentally disclose security issues
publicly because they don’t know better.”

Start Looking Into the Problem

You’ve shut things down, backed everything up, are displaying a static HTML page, emailed
security@djangoproject.com, and are looking at the problem. By following the above steps,
you’ve given yourself (and possibly your team) time to breathe and figure out what really
happened.

This will be a stressful time and people will be on the edge of panic. Start doing research,
perhaps in this book, ask questions as per Chapter 36: Where and How to Ask Django
Questions, and find a resolution.

Before you implement a correction, it’s often better to make sure you have a real, proper
fix for the problem then do a rushed emergency patch that destroys everything. Yes, this is
where tests and continuous integration shine.

Stay positive: now is the time for everyone to come together and fix the problem. Start taking
notes, ask for help from the best people you know, remind yourself (or the team) that you
have the will and the smarts to fix things, and make things right!

WARNING: The Nightmare of the Zero-Day Attack

Zero-day attacks are attacks on vulnerabilities that may be known to the public or
a closed list but still unpatched. For example:

ä Attacks the day of a software update release, right before most people get
around to installing the software update.
ä Attacks right after a user writes up a blog post about a vulnerability they found,
before package maintainers have the chance to write and release a patch.
ä Attacks targeting vulnerabilities in discussion on a closed security mailing list.

With zero-day attacks, there is often no time to address and patch the vulnerability,
making the compromise especially difficult to manage. If there was ever a reason to
have a battle plan for handling security issues, this is it.

See en.wikipedia.org/wiki/0day
Appendix H: WebSockets with Channels
Appendix H: WebSockets with Channels

Already mentioned in Chapter 27: Asynchronous Task Queues, Channels provides the ca-
pability for Django to handle WebSockets. The advantage of using Channels for this pur-
pose is that unlike alternative approaches such as FastAPI or Node.js , Channels allows us
to use Websockets in a way very similar to views. Better yet, by using Channels, we can ac-
cess our project’s code base, allowing us to access our models and other custom code. We’ve
found Channels to be a very powerful tool, especially when we follow the same practices we
espouse in the rest of this book.

Keep in mind that the advantage of WebSockets is much more than providing a real-time
interface. It’s that the protocol is lighter than HTTP. This makes it a faster way to transmit
data back and forth between client and server.

Here are our thoughts on using Channels based off lessons learned:

Each Browser Tab Has Its Own WebSocket Connection

If a user has one hundred tabs open to our project, then they are connecting to us with
one hundred WebSockets. As can be imagined, this causes browsers to crash and if enough
users share this behavior, can overload servers. While we can’t realistically force users to
close their tabs, we can optimize servers on our end. We cover this in Chapter 26: Finding
and Reducing Bottlenecks.

Another option is to track the number of WebSockets a particular user has to your system.
If they have more than twenty (or any number of your choosing) open, then close the con-
nections that don’t seem to be doing anything. We found this to be a pretty effective way of
protecting servers from unnecessary load. Unfortunately, there isn’t yet a stock solution for
resolving things in this manner.

Expect WebSocket Connections to Drop All the Time

WebSockets in Channels works very differently than the typical Django request-response
cycle. Instead of receiving an HTTP request from a user and then sending out an HTTP
Appendix H: WebSockets with Channels

response in the form of HTML or JSON, WebSockets open a constant connection, or

socket, between the server and the browser. Hence the term ‘WebSocket’.

The problem is that the odds are stacked against the connection’s survival. Let’s go over
some of what threatens it, shall we?

ä Small amounts of latency between the browser and the server

ä The server throws the equivalent of the 500 error
ä The server crashes
ä The browser tab crashing
ä The browser crashing
ä The user putting their computer to sleep

Rather than address this problem with some kind of long poll fallback like socket.io or
SockJS, Django Channels just lets the connection die. When this happens, the client has
to trigger a new connection. Conveniently, Django Channels provides a small JavaScript
library that creates a new connection when the old one dies.

The important thing in all this is to remember is that when using Channels we have to take
into account that long polling isn’t an option we can use.

Validate Incoming Data!

WebSockets provide another means for our users to send data to our project. As always,
validate incoming data before you do anything else with it. We’ve used both Django Forms
and Django REST Framework Serializers in this capacity. We cover the former technique
in depth in Section 13.1: Validate All Incoming Data With Django Forms.

Watch Out For Spaghetti Code

Alright, it’s time for an admission: Our first real effort with Channels turned into a nasty
plate of spaghetti code. We had a blast putting it together but when we were done we realized
our backend code was unmaintainable.

Later we took our time, leaned on the concept of fat models and helper files documented
as we worked, wrote better tests, and embraced Generic Consumers as if they were Class-
Based Views. In other words, we practiced what we preach.

In talking to other coders we discovered we weren’t the only ones whose first Channels
project turned out messy. The lesson learned from this is that in the excitement to play
with Django Channels, it’s easy to make basic mistakes. So do yourself a favor the first
time you write Channels code: Remember to take the time and use standard best practices.
Especially when it comes to writing tests: channels.readthedocs.io/en/stable/
topics/testing.html
Acknowledgments

This book was not written in a vacuum. We would like to express our thanks to everyone
who had a part in putting it together.

The Python and Django Community

The Python and Django communities are an amazing family of friends and mentors. Thanks
to the combined community we met each other, fell in love, and were inspired to write this
book.

Technical Reviewers for 3.x

These reviewers gave us their valuable time, helped caught our mistakes and pointed us in
the right direction on many occasions. Here they are in alphabetical order:

Adeyinka Adegbenro Adeyinka Adegbenro is a Software Engineer with a passion for com-
puter science and problem-solving. Outside of work, she enjoys writing(essays and
technical tutorials), working out, and watching documentaries. She lives in Lagos,
Nigeria.
Carol Willing is a member of Python’s Steering Council and a core developer of
CPython. She’s a Python Software Foundation Fellow and former Director. In 2019,
she was awarded the Frank Willison Award python.org/community/awards/
frank-willison/#carol-willing-2019 for technical and community contri-
butions to Python. With a strong commitment to community outreach, Carol co-
organizes PyLadies San Diego and San Diego Python User Group.
Enrique Matías Sánchez is a Software Engineer with a soft spot for System Administra-
tion. Besides programming, he enjoys outdoor sports (cycling, hiking, running, climb-
ing...) and learning to gibber in foreign languages. He lives in Zaragoza, Spain and
shares a black cat with his charming girlfriend Elena.
Haris Ibrahim K V is a human being working as a Software Developer since 2014 building
websites using primarily & Django in order to support his family. Enjoys teaching,
writing, singing, religion, learning, and banana roasted in ghee (as opposed to ice
cream, so there!).
Acknowledgments

Iacopo Spalletti tinkers with his computer for more time he would admit, Iacopo met
Python and Django in the late ’00s and he felt like home. He split his time building
things with clients and as opensource, working with the community as a speaker and
as organizer and mentor (meetups, Pycon Italia, DjangoCon Europe, DjangoGirls).
Lately focusing on avoiding too many bugs in raising a little human being.
Madelene Campos is a recovering professional musician, having earned 2 degrees in music.
Despite not studying computer science at University, web development seemed like a
natural extension to her musical studies. Programming and music are both powerful
and important communication tools. She started on this path in 2015, and has been a
professional developer since 2016. Maddie has been happily using Python and Django
for a little over 2 years, and hopes to continue on this glorious path!
Modasser Billah is a djangonaut whose favorite pet is Python. He loves to build enterprise
software systems in the cloud and currently works as a Lead Software Engineer at
BriteCore. Modasser is an AWS certified developer associate and a proponent of
leveraging the collective wisdom of software engineers known as best practices. He
loves remote work and teams without borders. Modasser has a Bachelor’s degree in
CS from Bangladesh University of Engineering & Technology and lives in Cumilla,
Bangladesh. When he is not coding, he is probably either enjoying today’s edition of
Dilbert or playing with his toddler daughters Naseeha and Naaera.
Renato Oliveira is a Brazilian Software Engineer and co-founder at Labcodes Software
Studio. He has been working with Python and Django for almost 10 years. He loves
creating sustainable web applications that don’t take forever to add a feature and also
helping others to accomplish their tasks.

Security Reviewers for 3.x

The following members of Django’s security team reviewed our material related to privacy,
authentication, crytography, and other security-related topics.

Florian Apolloner us a Software Engineer who loves debugging hopeless cases and find-
ing the root causes of weird bugs. He started contributing to Django around 2007,
became a member of the Django Team in 2012 and nowadays works as part of the Se-
curity Team. He enjoys biking and various winter sports and is living in the kangaroo-
free Austria (not Australia ;)).
James Bennett has been using and loving Django since almost the day it was released. He
spent five years working at the Lawrence Journal-World where he became directly
involved in the project, and has since served as a committer and release manager, a
member of the framework’s security team and technical board, and on the Board of
Directors of the Django Software Foundation. He now lives in California. Daniel and
Audrey met in his PyCon 2010 Djang Deep Dive tutorial, hence he is responsible for Two
Scoops of Django.
Markus Holterman (Security) - Markus Holtermann has been a member of several Open
Source communities and projects for over a decade. He gained experience in engineer-
ing, application and infrastructure security, and community management by taking on
tasks in these communities. Markus is a member of the security team for the Django
web framework and has given several conference talks about security in and around
Django. In his free time, Markus is a hobby photographer.
Michael Manfre is a software engineer with over two decades of involvement in Open
Source projects. He is a member of the Django web framework’s security team.
Michael’s Django contributions started in 2008 and initially focused on maintaining
a Microsoft SQL Server database backend and running Django on Windows.

Contributors to the 3.x Alpha

The following individuals helped us improve this edition by submitting corrections and
ideas for content: Luca Bezerra, Jane Upshur, Denis Morozov, Jack Pote, Sam Parting-
ton, Sim Kimsia, Nathan Hinchey, Kamil Kijak, Eman Calso, Jeff Maher, Veli Eroglu,
Davide Brunato, Ryan Harrington, Yong Shean, Laurent Steffan, Alexander Viklund,
Ramast Magdy, Steve Ratcliffe, Jeremiah Cooper, Arnav Choudhury, Keith Richards,
Victor David, Hugh Macdonald, Anthony Shaw, Andy Grabow, Lance Goyke, Edwin
Lileo, Tomi Okretič, Tim McCurrach, Ambrose Andrews, Remy Charlot, José Francisco
Martínez Salgado, Holger Rother, Mark Dobossy, Vlad Dmitrievich, Marek Turnovec,
Marcos Escalona, Bill Beal, Patrick Bollinger, Foad Mohammadi, Dominique Bischof,
Noah Lipsyc, Rakibul Islam, Michael Scharf, Mauro Allegrini

Technical Reviewers for 1.11

The following were critical in supporting the 1.11 edition of this book.

Matt Braymer-Hayes
Nathan Cox
Ola Sendecka
Jannis Gebauer
Haris Ibrahim K V
Tom Christie
Michael Herman
Humphrey Butau
Sasha Romijn - Security Reviewer
James Bennett - Security Reviewer
Florian Apolloner - Security Reviewer
Aymeric Augustin - Security Reviewer
Acknowledgments

Contributors to 1.11
The following individuals helped us improve this edition: Andrés Pérez-Albela H., Leila
Loezer, Martin Koistinen, Miguel Pachas, José Augusto Costa Martins Jr., Daniel Bond,
John Carter, Bernard ‘BJ’ Jauregui, Peter Inglesby, Michael Scharf, Jason Wolosonovich,
Dipanjan Sarkar, Anish Menon, Ramon Maria Gallart Escolà, You Zhou, Khaled Alqe-
naei, Xus Zoyo, Joris Derese, Laurent Steffan, Louie Pascual, Charlie Tian, Thijs van
Dien, Paulina Rybicka, Qi Ying Koo, Bassem Ali, Jonathan Mitchell, Anton Backer, Mar-
tijn Mhkuu, Photong, Michael John Barr, Kevin Marsh, Greg Smith, Muraoka Yusuke,
Michael Helmick, Zachery Tapp, Jesús Gómez, Klemen Strušnik, Peter Brooks, Bernat
Bonet, Danilo Cabello, Alenajk, Piotr Szpetkowski, Nick Wright, Michael Sanders, Nate
Guerin, David Adam Hernandez, Brendan M. Sleight, Maksim Iakovlev, and David Da-
han

Technical Reviewers for 1.8

The following were critical in supporting the 1.8 edition of this book.

Bartek Ogryczak
Barry Morrison
Kevin Stone
Paul Hallett
Saurabh Kumar
Sasha Romijn - Security Reviewer

Contributors to 1.8
Kenneth Love, Patrick McLoughlan, Sebastián J. Seba, Kevin Campbell, Doug Folland,
Kevin London, Ramon Maria Gallart Escolà, Eli Bendersky, Dan O’Donovan, Ryan Cur-
rah, Shafique Jamal, Russ Ferriday, Charles L. Johnson, Josh Wiegand, William Vincent,
Tom Atkins, Martey Dodoo, Krace Kumar Ramaraju, Felipe Arruda Pontes, Ed Patrick
Tan, Sven Aßmann, Christopher Lambacher, Colin O’Brien, Sebastien de Menten, Evan-
gelos Mantadakis, Silas Wegg, Michal Hoftich, Markus Holterman, Pat Curry, Gaston
Keller, Mihail Russu, Jean-Baptiste Lab, Kaleb Elwert, Tim Bell, Zuhair Parvez, Ger
Schinkel, Athena Yao, Norberto Bensa, Abhaya Agarwal, Steve Sarjeant, Karlo Tamayo,
Cary Kempston, José Padilla, Konstantinos Faliagkas, Kelsey Gilmore-Innis, Adam Bog-
dał, Tyler Davis, Javier Liendo, Kevin Xu, Michael Barr, Caroline Simpson, John Might,
Tom Christie, Nicolas Pannetier, Marc Tamlyn, Loïc Bistuer, Arnaud Limbourg, Alasdair
Nicol, and Ludvig Wadenstein.

Technical Reviewers for 1.6

The following were critical in supporting the 1.6 edition of this book.
Aymeric Augustin
Barry Morrison
Ken Cochrane
Paul McMillan - Security Reviewer

Technical Reviewers for 1.5

The following individuals gave us their invaluable help, aid and encouragement for the initial
release of this book. We give special recognition here to Malcolm for his contributions to
this book and the world.

Malcolm Tredinnick lived in Sydney, Australia and spent much of his time travelling in-
ternationally. He was a Python user for over 15 years and Django user since just after
it was released to the public in mid-2005, becoming a Django core developer in 2006.
A user of many programming languages, he felt that Django was one of the better
web libraries/frameworks that he used professionally and was glad to see its incredibly
broad adoption over the years. In 2012 when he found out that we were co-hosting
the first PyCon Philippines, he immediately volunteered to fly out, give two talks,
and co-run the sprints. Sadly, he passed away in March of 2013, just two months
after this book was released. His leadership and generosity in the Python and Django
community will always be remembered.

The following were also critical in supporting the 1.5 edition of this book.

Kenneth Love
Lynn Root
Barry Morrison
Jacob Kaplan-Moss
Jeff Triplett
Lennart Regebro
Randall Degges
Sean Bradley

Chapter Reviewers for 1.5

The following are people who gave us an amazing amount of help and support with specific
chapters during the writing of the 1.5 edition. We would like to thank Preston Holmes for
his contributions to the User model chapter, Tom Christie for his sage observations to the
REST API chapter, and Donald Stufft for his support on the Security chapter.

Contributors to 1.5
The following individuals sent us corrections, cleanups, bug fixes, and suggestions. This in-
cludes: Álex González, Alex Gaynor, Amar Šahinović, Andrew Halloran, Andrew Jordan,
Acknowledgments

Anthony Burke, Aymeric Augustin, Baptiste Mispelon, Bernardo Brik, Branko Vukelic,
Brian Shumate, Carlos Cardoso, Charl Botha, Charles Denton, Chris Foresman, Chris
Jones, Dan Loewenherz, Dan Poirier, Darren Ma, Daryl Yu, Dave Castillo, Dave Murphy,
David Beazley, David Sauve, Davide Rizzo, Deric Crago, Dolugen Buuraldaa, Dominik
Aumayr, Douglas Miranda, Eric Woudenberg, Sasha Romijn, Esteban Gaviota, Fabio Na-
tali, Farhan Syed, Felipe Coelho, Felix Ingram, Florian Apolloner, Francisco Barros, Gabe
Jackson, Gabriel Duman, Garry Cairns, Graham Dumpleton, Hamid Hoorzad, Hamish
Downer, Harold Ekstrom, Hrayr Artunyan, Jacinda Shelly, Jamie Norrish, Jason Best, Ja-
son Bittel, Jason Novinger, Jannis Leidel, Jax, Jim Kalafut, Jim Munro, João Oliveira, Joe
Golton, John Goodleaf, John Jensen, Jonas Obrist, Jonathan Hartley, Jonathan Miller,
Josh Schreuder, Kal Sze, Karol Breguła, Kelly Nicholes, Kelly Nichols, Kevin Londo,
Khee Chin, Lachlan Musicman, Larry Prince, Lee Hinde, Maik Hoepfel, Marc Tam-
lyn, Marcin Pietranik, Martin Báchtold, Matt Harrison, Matt Johnson, Michael Reczek,
Mickey Cheong, Mike Dewhirst, Myles Braithwaite, Nick August, Nick Smith, Nicola
Marangon, Olav Andreas Lindekleiv, Patrick Jacobs, Patti Chen, Peter Heise, Peter Valdez,
Phil Davis, Prahlad Nrsimha Das, R. Michael Herberge, Richard Cochrane, Richard Cor-
den, Richard Donkin, Robbie Totten, Robert Węglarek, Rohit Aggarwa, Russ Ferriday,
Saul Shanabrook, Simon Charettes, Stefane Fermigier, Steve Klass, Tayfun Sen, Tiberiu
Ana, Tim Baxter, Timothy Goshinski, Tobias G. Waaler, Tyler Perkins, Vinay Sajip, Vinod
Kurup, Vraj Mohan, Wee Liat, William Adams, Xianyi Lin, Yan Kalchevskiy, Zed Shaw,
and Zoltán Árokszállási.

Typesetting
We thank Laura Gelsomino for helping us with all of our LaTeX issues and for improving
upon the book layout.

Laura Gelsomino is an economist keen about art and writing, and with a soft spot for
computers, who found the meeting point between her interests the day she discovered
LaTeX. Since that day, she habitually finds any excuse to vent her aesthetic sense on
any text she can lay her hands on, beginning with her economic models.

We originally typeset the alpha version of the 1.5 edition with iWork Pages. Later editions
of the book were written using LaTeX. All editions up to 1.11 have been written on 2011
Macbook Airs. The 3.x edition was written on a mix of Macbook Pros and Macbook Airs.
List of Figures

1 Throwing caution to the wind. . . . . . . . . . . . . . . . . . . . . . . . xxx

1.1 Using import * in an ice cream shop. . . . . . . . . . . . . . . . . . . . . 7

2.1 Pip, virtualenv, and virtualenvwrapper in ice cream bar form. . . . . . . . 16

3.1 Yet another reason why repositories are important. . . . . . . . . . . . . . 21

3.2 Three-tiered scoop layout. . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 An isolated environment, allowing your ice cream to swim freely. . . . . . 25
3.4 Project layout differences of opinion can cause ice cream fights. . . . . . . 29

4.1 It’ll make more sense when you see the next figure. . . . . . . . . . . . . 31
4.2 Did that make sense? If not, read it again. . . . . . . . . . . . . . . . . . 32
4.3 Our vision for Icecreamlandia. . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Two small, single-flavor pints are better than a giant, 100-flavor container. 35

5.1 As your project grows, your Django settings can get pretty complex. . . . 43
5.2 While we’re at it, let’s go down this path. . . . . . . . . . . . . . . . . . . 60

6.1 Cones migrating south for the winter. Django’s built-in migration system
started out as an external project called South. . . . . . . . . . . . . . . . 70
6.2 A common source of confusion. . . . . . . . . . . . . . . . . . . . . . . 72

7.1 This flavor of ice cream contains raw SQL. It’s a bit chewy. . . . . . . . . 91
7.2 Because no one loves ice cream quite like a database. . . . . . . . . . . . . 95

8.1 Should you use an FBV or a CBV? flow chart. . . . . . . . . . . . . . . . 100

8.2 Loose coupling of chocolate chip cookie dough ice cream. . . . . . . . . . 102

9.1 If you look at sprinkles closely, you’ll see that they’re Python decorators. . 118

10.1 Popular and unpopular mixins used in ice cream. . . . . . . . . . . . . . . 122

10.2 The other CBV: class-based vanilla ice cream. . . . . . . . . . . . . . . . 128
10.3 Views + ModelForm Flow . . . . . . . . . . . . . . . . . . . . . . . . . 131
10.4 Views + Form Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

12.1 At Tasty Research, every flavor must begin with “Tasty”. . . . . . . . . . 145
12.2 Why would they do this to us? . . . . . . . . . . . . . . . . . . . . . . . 152

13.1 When ice cream validation fails. . . . . . . . . . . . . . . . . . . . . . . 166

14.1 An excerpt from the Zen of Ice Cream. . . . . . . . . . . . . . . . . . . 175

14.2 Two Scoops, official halftime sponsor of the Super Bowl. . . . . . . . . . 177
14.3 Bubble gum ice cream looks easy to eat but requires a lot of processing. . . 183

15.1 This filter transforms 1-2 flavors of ice cream into vanilla, outputting to a
cone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

17.1 An Ice Cream as a Service API. . . . . . . . . . . . . . . . . . . . . . . 217

17.2 A tasty pie is one filled with ice cream. . . . . . . . . . . . . . . . . . . . 229

19.1 Server-side vs. client-side ice cream. . . . . . . . . . . . . . . . . . . . . 241

20.1 Replacing more core components of cake with ice cream seems like a good
idea. Which cake would win? The one on the right! . . . . . . . . . . . . 248

21.1 Chocolate chip ice cream with an admin interface. . . . . . . . . . . . . . 253

21.2 Admin list page for an ice cream bar app. . . . . . . . . . . . . . . . . . . 254
21.3 What? An admin interface for ice cream bars? . . . . . . . . . . . . . . . 254
21.4 Improved admin list page with better string representation of our objects. . 255
21.5 Further improvements to the admin list page. . . . . . . . . . . . . . . . 256
21.6 Displaying URL in the Django Admin. . . . . . . . . . . . . . . . . . . 258

22.1 This looks strange too. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

23.1 A jar of Django’s mysterious secret sauce. Most don’t have a clue what this is.275
23.2 The secret is out. It’s just hot fudge. . . . . . . . . . . . . . . . . . . . . . 276

24.1 Test as much of your project as you can, as if it were free ice cream. . . . . 301

25.1 Even ice cream could benefit from documentation. . . . . . . . . . . . . . 315

26.1 With your site running smoothly, you’ll be feeling as cool as a cone. . . . . 326

29.1 CRITICAL/ERROR/WARNING/INFO logging in ice cream. . . . . . 362

29.2 Appropriate usage of DEBUG logging in ice cream. . . . . . . . . . . . . 366

31.1 A utility belt for serious ice cream eaters. . . . . . . . . . . . . . . . . . . 375

List of Tables

1.1 Imports: Absolute vs. Explicit Relative . . . . . . . . . . . . . . . . . . . 5

3.1 Repository Root Files and Directories . . . . . . . . . . . . . . . . . . . 23

3.2 Django Project Files and Directories . . . . . . . . . . . . . . . . . . . . 24

5.1 Settings files and their purpose . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 Setting DJANGO_SETTINGS_MODULE per location . . . . . . . . 47

6.1 Pros and Cons of the Model Inheritance Styles . . . . . . . . . . . . . . 64

6.2 When to Use Null and Blank by Field . . . . . . . . . . . . . . . . . . . 73
6.3 When to Use Null and Blank for Postgres Fields . . . . . . . . . . . . . . 77

7.1 When to Use Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 95

10.1 Django CBV Usage Table . . . . . . . . . . . . . . . . . . . . . . . . . . 124

14.1 Template Tags in base.html . . . . . . . . . . . . . . . . . . . . . . . . . 186

14.2 Template Objects in about.html . . . . . . . . . . . . . . . . . . . . . . 188

16.1 DTL vs Jinja2 Syntax Differences . . . . . . . . . . . . . . . . . . . . . 201

17.1 HTTP Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

17.2 HTTP Status Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
17.3 URLConf for the Flavor REST APIs . . . . . . . . . . . . . . . . . . . 213

20.1 Fad-based Reasons to Replace Components of Django . . . . . . . . . . 249

25.1 Documentation Django Projects Should Contain . . . . . . . . . . . . . 314

27.1 Should a Project Have a Task Queue? . . . . . . . . . . . . . . . . . . . 330

28.1 Password Strength: Length vs Complexity . . . . . . . . . . . . . . . . . 353

1 Translation Function Reference . . . . . . . . . . . . . . . . . . . . . . . 416

2 Security Settings Reference . . . . . . . . . . . . . . . . . . . . . . . . . 423
Index

–settings, 46, 47 AWS Lambda, 330

.gitignore, 26
<configuration_root>, 21 BASE_DIR, 59–61
<django_project_root>, 21, 23 Bottleneck Analysis, 94, 319–327
<repository_root>, 21, 23, 57
caching, 71, 176–177, 197, 247, 320, 321,
__str__(), 255–256
323–324, 327
{% block %}, 186, 188, 190
Cassandra, 248
{% extends %}, 188
CBVs, see Class-Based Views
{% include %}, 190
CDN, see Content Delivery Networks
{% load %}, 186
Class-Based Views, 99–111, 116, 119, 121–
{% static %}, 186
139, 190, 207, 320
{{ block.super }}, 186–189
clean() methods, 150, 151, 165
abstract base classes, 64–66, 82 Coding Style, 1–10
AbstractBaseUser, 266 Content Delivery Networks, 325, 344–345
AbstractUser, 265 Continuous Integration, 94, 306
ACID, 92, 248–251 Credit Cards, 349
Acknowledgments, 431–436 CSRF, 162–163, 243, 334, 339, 364
Additional Resources, 411–414 custom field validators, 145–147, 149
AJAX, 163, 207, 211, 243 Custom User models, 263–273
ALLOWED_HOSTS, 334
Angular, 238 database, 83
Apache, 50, 325 Database Migrations, 70
Environment Variables, 50 database normalization, 71
Argon2, 356 DEBUG, 46–48, 334
ASGI, 232 debugging, 393
assertions, 304 Decorators, 116–119
assets/, 24 denormalization, 71, 249, 251
Asynchronous Task Queues, 329 deployment, 400
Asynchronous Views, 141–142 Django Coding Style Guidelines, 7–9
ATOMIC_REQUESTS, 322 Django Packages, 275–292, 306
Avoid Using Import *, 6–7, 48 Django Templates and Jinja2, 201–206
Django’s Admin, 253–262 django.utils.html.strip_tags(), 377
Secure the Django Admin, 261–262 django.utils.html.timezone, 379
django-admin, 16, 19–21, 26–28, 47, 55 django.utils.translation, 379, 415–417
django-admin startproject, 19–21 django.views.generic.View, 121, 123–125,
django.contrib.admin, 253–262 136–138
django.contrib.admindocs, 259–262 DJANGO_SETTINGS_MODULE, 47
djangopackages.org, 202
django.contrib.auth.mixins.LoginRequiredMixin,
125–129, 131–133 Docker, 18
django.contrib.humanize, 375 Documentation, 259–262, 311–317
django.contrib.messages, 132–134 docutils, 259
django.core.exceptions Don’t Repeat Yourself, 43, 45, 101, 104, 106,
ImproperlyConfigured, 379 154, 199, 299
ObjectDoesNotExist, 379–380
Enumeration Types, 76–77
PermissionDenied, 114, 380 environment variables, 49–57
django.core.serializers Environment Variables Pattern, 49–55, 421
json.DjangoJSONEncoder, 383 Error Page Templates, 192–193
pyyaml, 384 eval(), 341
xml_serializer, 384 exec(), 341
django.db, 63–82 execfile(), 341
django.db.migrations, 67–70 Explicit Relative Imports, 5–6
django.db.migrations.RunPython.noop, 68–
69 Fat Models, 80–81
django.db.models, 63–80 FBVs, see Function-Based Views
django.db.transaction, 92–96 FileField, 72
filters, 195–196, 300
django.forms.renderers.TemplatesSetting,
169 fixtures, 12, 299–300
form.is_valid(), 165
django.http.HttpResponse, 127, 228
form_invalid, 167
django.http.HttpResponseForbidden, 380
form_invalid(), 127–128
django.http.HttpResponseRedirect, 127
form_valid(), 126–127, 132–134, 165
django.http.JsonResponse, 228
Forms, 6, 126–136, 143–171, 343–344,
django.http.StreamingHttpResponse, 96
346–348
django.utils.decorators
FrankenDjango, 247
decorator_from_middleware, 376
Function-Based Views, 93, 99–111, 113–
method_decorator, 376
119, 136–138, 207
django.utils.encoding.force_text, 376, 419
functools.wraps(), 118
django.utils.functional.cached_property,
376 GCBVs, see Generic Class-Based Views
django.utils.html.format_html(), 339–340, Generic Class-Based Views, 121, 123–125,
377 137–139, 403–404
 Index

get_absolute_url(), 257 KISS, xxxii–xxxiii

get_env_variable(), 54, 55
get_object_or_404(), 83, 380 Let’s Encrypt, 335
get_secret(), 55–57 license, ii
Git, 17, 20, 278, 280 Linux, 12, 17, 25, 51, 368, 408
git tag, 289–290 list_display, 256
GitHub, 17, 26, 276, 278–280, 353 local_settings anti-pattern, 43–45, 49, 55,
GitLab, 17, 280 421
god object, 80 logging, 361–369
GraphQL, 37, 231–235 CRITICAL, 362
Grunt, 10 DEBUG, 362, 364–366
Gulp, 10 ERROR, 362, 363
exceptions, 366–367
Heroku, 53, 425 INFO, 362, 364
HIPAA, 336 WARNING, 362, 364
HttpRequest, 113–118, 429 logrotate, 368
HttpResponse, 117–119, 430 Loose coupling, 101–102, 104

i18n, 415–420 Mac, 12, 17, 25, 51, 368, 408

ImproperlyConfigured, 55 makemigrations, 67
indexes, 91–92, 97 manage.py, 16, 55
INSTALLED_APPS, 31, 259 mark_safe, 339
intcomma, 375 Markdown, 281, 311, 316
Integration Tests, 305–306 Memcached, 248, 321–323
is_valid(), 165 Mercurial, 280
Meta.exclude, 346–348
JavaScript, 237–245
Meta.fields, 346–348
Jinja2, 201–206
method resolution order, 123
context processors, 205
MIGRATION_MODULES, 67
CSRF, 203
Migrations, 67–70
Django-style Filters, 203–205
mixins, 121–123, 133, 134, 158, 374
jinja2.Environment, 205–206
model _meta, 77–78
Template Tags, 203
Model Choice Constants, 75–77
JQuery, 238, 240
model managers, 78–80
JSCS, 10
ModelForms, 143, 144, 147–149, 153, 165,
JSON, 55–57, 137, 207, 209–214, 218–219,
166, 346–348
296, 299–300, 334, 340, 342–343,
models, 6, 63–82
381–384
models.field.BinaryField, 72–74
Keep It Simple, Stupid, xxxii–xxxiii warning, 72–74
kept out of version control, 44 models.field.GenericForeignKey, 74–75
MongoDB, 248 django-axes, 402
Mozilla, 419 django-background-tasks, 400
multi-table inheritance, 64–67 django-braces, 121, 229, 320, 404
Multiple Settings Files, 45–49 django-cachealot, 324
MySQL, 12, 70, 96, 181, (�)248, 248, 322, django-cacheops, 324
323 django-compressor, 325, 404
django-crispy-forms, 143, 198, 284,
NASA, xxvii, 293 401
Never Code to the IDE, 10 django-csp, 341, 402
Nginx, 55, 325 django-debug-toolbar, 46, 108, 291,
node.js, 429 319–322, 399
NoSQL, 248–251 django-extensions, 63, 82, 320, 404
django-extra-views, 139
Open Source Initiative, 285
django-floppyforms, 143, 401
Open Source Licenses, 285
django-haystack, 404
OpenAPI, 227–229
django-htmlmin, 325, 404
ORM, xxxiii, 11–12, 63–97, 134, 165, 179,
django-js-reverse, 404
181, 182, 248, 267, 282, 300, 320,
django-jsonview, 229, 402
348–349, 419
django-maintenancemode, 426
PaaS, see Platforms as a Service django-maintenancemode2, 400, 426
Packages A-D django-model-utils, 63, 82, 399
, 340 django-pipeline, 325, 404
aldjemy, 400 django-registration, 403
Black, 2–3 django-rest-framework, 162–163, 207–
bleach, 402 230, 402
cached-property, 376–377 django-reversion, 404
celery, 183, 400 django-rq, 400
Conda, 14 django-secure, 352
conda, 399 django-stronghold, 402
Cookiecutter, 19, 26–28 django-tastypie, 229, 402
cookiecutter, 286–287, 291, 402 django-two-factor-auth, 402
cookiecutter-django, 26–28 django-user-sessions, 402
coverage.py, 294, 306–309, 403 django-vanilla-views, 139, 404
crispy-tailwind, 401 django-watson, 404
defusedxml, 345, 351, 384, 402 django-webpack-loader, 325
dj-stripe, 404 dynaconf, 401
Django Channels, 183, 400, 429–430 flower, 400
django-admin-honeypot, 261, 402 python-slugify, 378, 405
django-allauth, 403 rest_framework.serializers, 384–385
 Index

Packages E-O sphinx, 280, 281, 311–315, 401

envdir, 404 stylelint, 10
ESLint, 9–10, 401 supervisor, 400
fabric, 23 tox, 403
factory boy, 300, 403 twine, 288–289, 403
flake8, 3, 405 venv, 13
Interrogate, 305, 316 virtualenv, 13, 15, 24–26, 51, 52, 259,
invoke, 23, 400 277, 279, 291, 400, 408, 409
ipdb, 399 virtualenvwrapper, 15, 52, 400
isort, 4, 405 virtualenvwrapper-win, 400
jinja2, 201–206, 248 Zappa, 57
logutils, 368 pandoc, 316
Mock, 302–304 PBKDF2, 356
mock, 300, 403 PCI, 349
model bakery, 300, 403 PEPs
Packages P-Z PEP 257, 315
Myst-Parser, 401 PEP 328, 6
nox, 403 PEP 427, 289
pathlib, 60–61 PEP 8, 2–4, 6
paver, 23 Personally Identifying Information, 349–
pendulum, 404 350
pillow, 399 PHI, 349–350
pip, 13, 16, 259, 276–277, 280, 284, pickle, 341–343
285, 291, 399, 409 PII, 349–350
pip-tools, 405 platform.sh, 53
Pipenv, 14 POLP, 336
pipenv, 399 PostgreSQL, 11, 12, 91, 181, 248, 251, 321,
poetry, 14, 400 323
psycopg2-binary, 400 PowerShell, 51
pytest, 403 Principle of Least Privilege, 336
pytest-django, 403 print(), 364–366
python-dateutils, 404 Project Templates, 19–29, 421–422
python-decouple, 401 cookiecutter grid, 19
python-social-auth, 403 cookiecutter-django, 19, 26–28, 401
pytz, 404 cookiecutter-django-vue-graphql-aws,
pyYAML, 341–342, 384, 405 19, 28, 402
requests, 405 cookiecutter-djangopackage, 286, 291
rq, 400 cookiecutter-pylibrary, 286
silk, 320, 405 django-crash-starter, 402
Protected Health Information, 349–350 LoginRequiredMixin, 126
Proxy Models, 269–273 Mass Assignment Vulnerabilities, 348
proxy models, 64, 65 pickle, 341
PyPI, 276, 280, see Python Package Index Planning for Disaster, 353, 425–427
Python Anywhere, 53 PyYAML security warning, 341–342
Python Package Index, 266, 276, 284–285, Secure the Django Admin, 261–262
288–289, 292 SECURE_PROXY_SSL_HEADER,
PYTHONPATH, 16, 47 424
SecurityMiddleware, 352
queries, 83 SESSION_SERIALIZER, 424
Settings Reference, 423–424
Rails, 37–41
SSL, 335–336
Rate-Limiting Your API, 225–227
strip_tags, 377
React, 237
TOTP, 351–352
README.md, 28
Two-Factor Authentication, 351–352
README.rst, 21
Use format_html, 258
Redis, 248, 322, 323
Vulnerability Page, 353
Remote Procedure Calls, 220–222
XML bombs, 351
requirements, 57–59
XSS, 339–341
requirements.txt, 21, 25
Zero-Day Attack, 353, 427
requirements/, 57
security
REST APIs, 207–230
Content Security Policy, 340–341
ReStructuredText, 315–316
select_related(), 182, 320
Ruby on Rails, 37–41
Sentry, 369, 401
SECRET_KEY, 43–45, 49–57, 334–335 Serverless, 330
Secrets File Pattern, 55–57, 421 Service Layers, 37–40
Secure Password Managers, 353 settings, 23, 43–62
Security, 333–359 settings/base.py, 60, 61
2FA, 351–352 settings/local.py, 46, 47, 50
Checkups, 353 settings/base.py, 54
Clickjacking, 350–351 signals, 371
Code Injection Attacks, 341 Single Page App, 237
Cookie-based sessions, 342–343 site_assets/, 24
CSRF, 162–163, 339 slugify(), 195, 377–378
CSRF and Jinja2, 203 smoke test, 293
defusedxml, 351 Sphinx, 280
django-admin-honeypot, 261 SQLite3, 11, 12
HSTS, 337–339 sqlmigrate, 67
HTTPS, 335–339 squashmigrations, 67
 Index

SRI, 356–358 WSGI, 23, 232, 324

STATICFILES_DIRS, 24
XML, 55–57, 207, 334, 345, 381, 384
stylelint, 10
XML bombs, 351
Subresource Integrity, 356–358
syntactic sugar, 116 YAML, 55–57, 207, 334, 341, 381, 384
template tags, 10, 195, 197–200, 300 YAML and PyYAML security warning, 341
templates, 21, 23, 28, 59, 61, 132, 134, 136,
Zen of Python, 175–176, 200
173–193
TEMPLATES OPTIONS
string_if_invalid, 191
test coverage, 306–309
Testing, 94, 293–310, 374–375
TimeStampedModel, 65
Tips for Creating Database Migrations, 67
Transactions, 92–96
ATOMIC_REQUESTS, 92–94
MySQL, 96
Twelve Factor App, 421–422

Unicode, 376, 415, 419

unit tests, 295
Upstream Caches, 325
URL namespaces, 104–108
URLConfs, 21, 23, 100–108, 111, 191, 259,
285–286, 381
User model, 263–273
Utility Modules, 374–375

validation, 12, 143–171

Vanilla JavaScipt, 238
Vanilla Steak, 124
Varnish, 325
Vue, 238

Webpack, 10
webpack, 241
Websockets with Django Channels, 429–
430
wheel, 289, 292
Windows, 12, 15, 17, 25, 51, 368, 408