DEV Community: James Timmins

Django Cheat Sheet: Keep Credentials Secure with Environment Variables

James Timmins — Tue, 17 Sep 2019 17:05:30 +0000

Tl;DR
Hard coding config values and credentials is convenient but makes your code less secure and less portable. Use environment variables to make your code more secure and easy to deploy in different environments.

Bad:

TWILIO_SECRET_KEY = "iamverysneaky"
twilio_client = Twilio(key=TWILIO_SECRET_KEY)

The problem:
If someone gets access to your code, now they have access to your Twilio account too! Two problems for the price of one!

Good:

from dotenv import load_dotenv

load_dotenv()

twilio_client = Twilio(key=os.getenv("TWILIO_SECRET_KEY"))

If someone gets access to your code, at least your Twilio account (and user data!) is still safe.

To illustrate how this works, we'll move the auto-generated SECRET_KEY value out of settings.py and into an environment variable.

From this:

SECRET_KEY="thisismyunsecuredsecretkey"

To this:

SECRET_KEY=os.getenv("DJANGO_SECRET_KEY")

Do these things:

Download the dotenv package.
```
$ pip install python-dotenv
```
Create a file named .env in the same directory as settings.py.
```
$ touch .env
```
Add the .env file to your .gitignore. This is the most important step bc it keeps .env, and thus your secret values, outside of version control/Git.
```
$ echo .env >> .gitignore
```

Add your config values and credentials to .env.

$ echo 'DJANGO_SECRET_KEY="thisismyunsecuredsecretkey"' >> .env

Import and loados and dotenv into settings.py. This makes the values accessible.
```
import os
from dotenv import load_dotenv
...
load_dotenv()
```
Replace the original SECRET_KEY value with an environment variable lookup.
```
SECRET_KEY=os.getenv("DJANGO_SECRET_KEY")
```
Profit! By not getting sued by your users for letting their data get stolen. GDPR goodness!

I'm writing a book about Django -- What do you want to learn?

James Timmins — Thu, 08 Aug 2019 21:04:56 +0000

Hi folks!

In my previous post, I talked about the book I'm working on that covers building and deploying Django APIs for MVPs and portfolio projects.

Now that I'm a few chapters in, it seems like a good time to check back in with folks to hear their additional thoughts and get feedback on our overall direction.

If anyone is learning Django, has learned Django, wants to learn Django, or tried and was intimidated, it would be really helpful to hear your thoughts and specifically what was challenging or confusing when you were first starting out.

If you click this link for a Typeform feedback form, you can fill out a few questions and share your thoughts.

Assuming that enough people respond, in a few weeks I will share the results and my up-to-date outline for the book and how it incorporates that feedback.

Thank you so much!

If you're interested in following me you can do so at @jamestimmins, and if you'd like to hear more about the book you can sign up for updates at the official site.

Why we’re writing a Django book specifically for portfolio projects and MVPs

James Timmins — Thu, 13 Jun 2019 17:31:57 +0000

TLDR: The hardest part of building web applications is rarely using the framework itself or even the “business logic”. It’s cleanly integrating your app into all of the other tools involved in a modern web app. So we’re writing a book specifically about building and deploying a production-ready Django API that you can be proud of.

I remember feeling stupid while I was first learning about web programming. I picked Django because I liked Python, and while there were great resources online, it never felt like I knew quite enough to put a project I was proud of onto Github or Hacker News.

Most documentation and tutorials only covered building something that you could run safely on your own computer, or they were way too technical for me. Every time I tried to integrate with a new tool or service there were new headaches and problems that slowed my progress. It took years for me to feel confident showing off the apps I built.

I didn’t want to build toy applications. I wanted to build production apps that were safe and scalable enough to release onto the open web.

When my co-author Bryan and I started planning Fullstack Django APIs, we asked what problems existed within the Django ecosystem in general, and Django Rest Framework in particular. We could write a huge reference book on Django, but that seemed like a waste of time. Django already has expansive, mature documentation online. Books like Two Scoops of Django and Test Driven Development with Django are gold standards in their respective domains. We wanted to create something that complemented the existing materials, rather than trying to compete with it.

So we outlined areas of confusion. They included:

How do I deploy a live production application?
Where do I put my business logic?
How do I store configs and credentials in a secure manner?
How do I handle authentication?
What type of DB should I use and how do I connect to it on my own computer vs a live, production database.
How do all of the pieces of Django fit together?
What are task queues and when should I use them?
To cache or not to cache?

It eventually became clear that those areas of confusion weren’t unique to just us. Lots of new Djangonauts get excited about the possibility of making and deploying cool projects, but are bogged down by the difficulty of integrating their APIs into a broader development environment.

So that’s who we’re writing a book to help. Our goal is for junior and intermediate level developers to work through Fullstack Django APIs and leave with the confidence and skills needed to make a production-ready API. Something that they can show to recruiters or clients, and feel comfortable using to build live web services that store data from real users.

If we’re successful, this is something that every tech company using Django will give to new hires so they’re ready to write production code. We know that’s an ambitious goal, but we’re excited about the progress that we’ve already made in this area. I’ll get more specific with the details as we near the release date, but until then, I’m excited to share more about the process here on Dev.to.

If you’re interested in the project and would like access to the first chapter once it’s released, you can sign up here to stay in the loop.