DEV Community: Rob McBryde

Django Secret Key

Rob McBryde — Mon, 15 Jan 2024 12:07:02 +0000

When you start a new Django project, your settings.py file contains a 'SECRET_KEY' entry by default.

Both the comments and the secret key values itself both indicate that this is insecure and should not be exposed.

The SECRET_KEY' is a random 50-character string generated each time startproject is run. It is used to provide cryptographic signing in our project.

When working on a Django project that you intend to place into a production environment, you should move this secret key into a .env file.

I have used the environs package to manage my environment variables, which I have previously written about.

Creating an .env file

Create a file named .env in the root directory of your project and in it paste in your secret key from your settings.py file:

SECRET_KEY=django-insecure-egyi&vxcm6kkpkaa&wnw0+&ps6%4-s@&c=+891+jfu8j5*adz4

Note there are no spaces in the .env file

Now update your settings.py file to read your secret key from your environment variable:

# settings.py file
SECRET_KEY = env.str("SECRET_KEY")

Regenerating your secret key

Even though our SECRET_KEY is out of our settings.py file we potentially aren't safe yet. If you have made any Git commits before doing this change, our secret key is stored in our Git history. Anyone who can access out source code and Git history can see it.

The solution is to create a new SECRET_KEY and add it to our .env file. First ensure that you have created a .gitignore file in the root directory of your project and add a .env entry to it so that Git will not track it.

In order to generate a new SECRET_KEY is by invoking Python's built-in secrets module by running the following from your terminal:

python3 -c "import secrets; print(secrets.token_urlsafe())"

Now paste this new randomly generated secret into your .env file overwriting the SECRET_KEY entry. Ensure that there are no quotes (" or ') surrounding your pasted key and that there are no spaces between the equals sign and your key in the .env file.

Now you have a more secure secret key!

Django environment variables

Rob McBryde — Wed, 03 Jan 2024 13:09:50 +0000

As per the twelve-factor app methodology it is important to store config outwith the program that can be injected in at runtime.

Not only does this keep sensitive information secure such as our passwords and API keys. Additionally it allows us to make us of a single settings.py file to load either out local or production environments variables.

There are many options for doing this, but the Django community seems to like environs as it comes with additional Django support built-in.

To install it via pip:

python3 -m pip install "environs[django]"==9.5.0

Then add these three lines to the top of yout project/settings.py file:

from environs import Env 

env = Env()
env.read_env()

Database config using environment variables

An example use case is configuring our project to use a SQLite database locally, but a PostgreSQL database in production.

The environs package comes installed with dj-database-url. A package that allows us to set a DATABASE_URL that is utilised by most PaaS providers.

With a very small amount of code in our project/settings.py file, we can configure our project to try to access a DATABASE_URL environment variable. If it exists it will be used and our project will access our 'production' PostgreSQL database, if one can't be found then it will default to SQLite, e.g. locally.

Change the default 'DATABASES' section in your settings.py file from this:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": BASE_DIR / "db.sqlite3",
    }
}

To this:

DATABASES = {
    "default": env.dj_db_url("DATABASE_URL", default="sqlite:///db.sqlite3"),
}

Configuring as PostgreSQL database in Django

In order to use a PostgreSQL database we need an adapter that allows Python to communicate with a PostgreSQL database. The community seems to favour Pyscopg for this.

If you are on a Mac like me, you will also need to have installed PostgreSQL via homebrew first:

brew install postgresql
python3 -m pip install "psycopg[binary]"==3.1.8

Deploying your first Django App

Rob McBryde — Tue, 02 Jan 2024 14:12:11 +0000

When you create a Django project using the startproject command, settings are default for local development, many of which are not appropriate in production.

As a simple starter I want to learn how to deploy a Django application into production using a Platform as a Service provider (PaaS).

For that I will need a Python WSGI(Web Server Gateway Interface). I will be using Gunicorn for this.

Gunicorn

Gunicorn replaces the Django local development server and is installable with pip:

python3 -m pip install gunicorn==20.1.0

Requirements file

Once installed, in my Django projects virtual environment, I need to ensure that a valid requirements.txt file exists containing all the python packages needed to run our project:

python3 -m pip freeze > requirements.txt

Django project settings

I now need to update the ALLOWED_HOSTS list in my django-project/settings.py to represent which host/domain that my site can serve.

This is a security measure to prevent HTTP Host header attacks. When getting started you can simply use "*" wildcard in order to allow all domains, but make sure you configure this more specifically for your projects going forwards.

Docker ignore file

Finally I am going to create a .dockerignore file in the project root directory. As a minimum, I want to ignore our local virtual environment, SQLite database an Git repo.

# .dockerignore file contents
.venv/
*.sqlite3
.git

Fly.io

I have previously used Heroku for side project hosting, however as of Nov 2022, Heroku (understandably) no longer offer a free tier.

I will therefore be using Fly.io to host my app. You will need to sign up for an account and a payment method. In my experience, provided you site isn't attracting traffic and costs less than $5 per month, then Fly.io wave the fees and it is free.

Fly has its own CLI (Command Line Interface) which you can install following the official docs

Once installed we login:

flyctl auth login

I then run the fly launch command to configure and launch my site:

fly launch

Provided you do this in the terminal within your virtual environment at the root of your project, Fly should automatically detect you are running a Django app. Make sure you don't overwrite the .dockerignore file.

Once complete you should see two new files in your project directory.

fly.toml
Dockerfile

The fly.toml is a Fly-specific config file and the Dockerfile contains instructions for creating a Docker image on Fly servers.

deploying on Fly

To deploy our app onto Fly servers run the following

flyctl deploy

The initial deploy will take a few seconds as it comprises of uploading your application, verifies the app configuration, builds the Docker image and then monitors to ensure the app starts successfully.

Once complete, you can visit your app in production with fly open command:

fly apps open

If you have any issues you can view the logs via fly logs.

Note: I'm not quite sure why some Fly commands require flyctl while others require fly, if in doubt check their docs.

Summary of deployment

Our Django site is running on a Docker virtual machine created via the Dockerfile in our project. The fly.toml configures our website settings and can be modified as needed.

You can run fly dashboard via the command line to load uour browser-based view to manage your Fly deployments.

Caveats

I have taken several security shortcuts here as my goal is purely to push my first project into production in as few steps as possible. This steps are not advisable for real production systems that will be used in anger.

I intend to document proper security around deployments in the future as my learning continues.

I also haven't compiled static files into one location for production. That too is something I will explore as I continue to learn. This really was about deploying the most minimal app to production.

Django tests

Rob McBryde — Tue, 02 Jan 2024 11:56:40 +0000

Code without tests is broken as designed - Jacob Kaplan-Moss (Django co-creator)

I am a fan of TDD (test driven development) and get nervous anytime I am working with a codebase that does not have a robust automated testing framework.

Therefore, it's important as part of my learning Django to try out the testing framework to see how it feels to work with.

According to the Django official docs the preferred testing approach is using the unittest module that is built-in to the Python standard library.

Django's testing framework provides several extensions on top of the standard unittest.TestCase base class. These include a test client for making dummy Web browser requests and four test case classes:

SimpleTestCase
TestCase
TransactionTestCase
LiveServerTestCase

An overly simplified summary of their use cases is SimpleTestCase is used when a database is unnecessary. While TestCase is used when you want to test the database.

TransactionTestCase is helpful to directly test databases transactions while LiveServerTestCase launches a live server thread for testing with browser-based tools such as Selenium.

One strange convention I found was the fact the unittest and django.test methods are written in camelCase rather than the standard snake_case pattern normally found in Python. Apparently, this stems for the fact that unittest is based on the jUnit testing framework from Java which utilises camelCase. This seems a bit bizarre to me, but I will stick with the communities conventions.

Testing with a database

When testing with a database, we need to use TestCase, which will let us create a test database. In other words, we don't need to run tests on our actual database. Instead we can make a separate test database, fill it with sample data pertinent to our scenarios, then test against it.

This is much safer and a more performant approach to testing against our actual production database.

To make use of this, we use the hook setUpTestData() to create our test data; it is much faster thatn using the setUp() hook from Python's unittest because it creates the test data only once per test case rather than per test.

Note: test functions must start with the word "test" to be run.

Django Views

Rob McBryde — Tue, 02 Jan 2024 11:22:51 +0000

As of the day I write this post, Django supports 3 ways to create a view:

function-based
class-based
generic class-based

Most problems you are trying to solve have probably already been done via a generic class based view. If it hasn't it is often possible to modify one of the generic views to suit your needs.

This will be my default approach to always utilise a generic class based view. Failing that I will fall back to creating a class-based view, then a function-based view.

For further learnings on this topic, check out the very useful Classy Class-Based Views site.

Embarking on a Django journey - Coding for the joy of it

Rob McBryde — Fri, 29 Dec 2023 14:13:29 +0000

Django setup on Mac with venv, PyCharm and Black.

As a software engineering manager entrenched in the world of people management and administrative tasks, the yearning to reconnect with the sheer joy of coding has led me to explore a new and exciting realm: the Django framework in Python. In this blog post, I'll share the motivations behind this creative coding endeavour and delve into the initial steps of setting up a development environment on my Mac.

A Creative Coding Escape

Amidst the hustle of managerial responsibilities, I found myself yearning for a coding outlet that could both rekindle the joy of programming and introduce me to unfamiliar territories. Django, a high-level web framework written in Python, presented itself as an intriguing choice. The decision to delve into a language I have limited professional experience with and a framework entirely unexplored felt perfect for me.

Setting the Stage: Python and Django on Mac

The first step on this journey involved setting up a development environment tailored for Python and Django on my Mac.

Pyenv

In my experience it is always advisable to install a version manager when working with programmgin languages where possible. Your future self will help you for it if you start to work on multiple projects in the future. In order to install Python 3 onto my Mac I used pyenv which I installed via Homebrew.

Python virtual environments

Consider working on multiple Django projects at once. Project A uses Django 3.2, but Project B uses Django 4.2. By default, Python and Django are installed globally on a computer: installing and reinstalling different versions every time you want to switch between project, quickly becomes a real pain.

Virtual environments allow you to create and manage separate environments for each Python project on the same computer. Within the Python community, the use of virtual environments seems non debatable. I have opted to use venv which comes installed as part of Python version 3.3, so fits my needs perfectly.

I am using the convention of creating a .venv directory alongside each of my Django projects.

mkdir helloworld
cd helloworld
python3 -m venv .venv
# active the virtual environment
source .venv/bin/activate
python3 -m pip install django~=4.2.0

The above command to install Django in my virtual environment uses the comparison operator ~=, which installs the latest version of Django 4.2.x.

I didn't use pip install but rather python3 -m pip install? The former does work, but according to my reading around the Python community, it can cause some issues. Using the latter version of the comman ensures that the intended vesion of Python is in use, even if you have multiple versions of Python installed in your machine. Given that Macs often have Python 2.7 installed, it seems like a sensible approach to me to ensure the intended version of Python is being used.

Crafting Code in Comfort: PyCharm IDE

Choosing the right Integrated Development Environment (IDE) is crucial for a seamless coding experience. Enter PyCharm – my preferred IDE for this Django expedition. Its robust features, intelligent code completion, and Django support make it an invaluable companion for navigating the intricacies of web development. The comfort of PyCharm enhances the joy of coding, allowing me to focus on creativity rather than grappling with the tool. I'm a long term fan of JetBrains, so sticking with what I know.

Code Formatting Bliss with Black

No coding journey is complete without attention to code formatting. Enter "Black," the uncompromising code formatter for Python. Its opinionated approach streamlines the process, ensuring consistent and readable code. Integrating Black into the workflow not only adheres to best practices but also eliminates unnecessary debates over code styling.

python3 -m pip install black

As of PyCharm 2023.2, Black integration has been possible via Settings > Tools > Black. Simply select your Python interpreter as your (helloworld) virtual env. FYI I'm currently using Python 3.10 but will no doubt change soon enough (easily due to pyenv). I happen to like the Black formatter running 'On save'

Conclusion

That's my basic setup complete.

In the coming posts, I'll be documenting my learning experiences, pitfalls, and triumphs in the Django universe. While the primary aim is personal growth and enjoyment, I hope this documentation serves as a valuable resource for others venturing into Django development. Here's to coding for the sheer thrill of it!