Use data provided by default Django context processors on Django templates

Problem

You want to access application data provided by the default Django context processors on a Django template

Solution

Use standard Django template syntax to gain access to the data exposed by the default Django context processors.

How it works

By default, Django templates have access to several generic application data variables. This eliminates the need to constantly expose common data from Django view methods or url extra options. These generic application data variables are made available through template context processors. You can think of template context processors as behind the scenes view methods that expose data for all Django templates.

Django template context processors are explicitly defined in a project's settings.py. If you look for the TEMPLATES variable, inside the OPTIONS key, you'll see the context_processors definition illustrated in listing 1.

Listing 1 - Default template context processors in Django

        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
	 }

As illustrated in listing 1, Django template context processors use the same Python package syntax as Django apps or Django views. I'll describe the structure of Django template context processors in the next recipe which describes how to create custom context processors. Next, I'll describe the data variables made available by each of these context processors.

Django debug context processor (django.template.context_processors.debug)

The Django debug context processor exposes data variables helpful for debugging. This context processor makes the following variables accessible in Django templates:

Note Define INTERNAL_IPS in settings.py to view the values of debug context processor variables

The Django debug context processor displays its variable values only if the requesting IP address is defined in the INTERNAL_IPS variable in settings.py. Even if the variables are declared in a template (e.g.{{debug}} or {{sql_queries}}) this restriction permits that only certain users view the debug messages in the template, while other users won't view anything.

For example, to view the debug and sql_queries values on your local workstation, add INTERNAL_IPS = ['127.0.0.1'] to the settings.py file. This tells Django to display these variables values for requests made from the IP address 127.0.0.1 (i.e. your local workstation).

Django request context processor (django.template.context_processors.request)

The Django request context processor exposes all data variables related to a request (i.e. HTTP request). This context processor makes data available through a massive dictionary named request in Django templates that include some of the following key-values:

Django auth context processor (django.contrib.auth.context_processors.auth)

The Django auth context processor exposes data variables related to authentication logic. This context processor makes the following variables accessible in Django templates:

Django messages context processor (django.contrib.messages.context_processors.messages)

The Django messages context processor exposes data variables related to the Django messages framework -- described in greater details in Set up flash messages in Django view methods for notifications. Messages are added from Django view methods to the message framework, which are then exposed in a template. This context processor makes the following variables accessible in Django templates:

Other built-in Django context processors: i18n, media, static, tz & CSRF context processors

The previous context processors are the most common built-in context processors which is why they're enabled by default, however, this doesn't mean they are the only ones. There are in fact five more built-in context processors you can use to always access certain data from Django templates.

Django i18n context processor (django.template.context_processors.i18n)

The Django i18n context processor exposes data variables related to internationalization logic. This context processor makes the following variables accessible in Django templates:

Django media context processor (django.template.context_processors.media)

The Django media context processor exposes a data variable related to media resources. This context processor makes the following variable accessible in Django templates:

Django static context processor (django.template.context_processors.static)

The Django static context processor exposes a data variable related to static resources. This context processor makes the following variable accessible in Django templates:

Note Don't use the static context processor or STATIC_URL in templates

Using the STATIC_URL variable in templates is no longer recommended, you should use the staticfiles app instead. More details are provided in the recipe Set up static web page resources -- Images, CSS, JavaScript

Even though the static context processor is still available (i.e. it's not deprecated) its functionality is outdated and should be avoided.

Django tz context processor (django.template.context_processors.tz)

The Django tz context processor exposes a data variable related to a project's time zone. This context processor makes the following variable accessible in Django templates:

Django CSRF context processor (django.template.context_processors.csrf)

The CSRF ('Cross Site Request Forgeries') context processor adds the csrf_token variable to all requests. This variable is used by the {% csrf_token %} template tag to protect against Cross Site Request Forgeries.

Although you can gain access to the csrf_token variable value on any Django template, you will have little -- if any -- need to expose it directly, as it's used as a security mechanism to detect rogue requests. In Set up Django forms - CSRF: What is it and how does it work with Django ? you can explore the overall need and purpose of CSRF.

Due to the security significance of having the csrf_token variable available on all requests, the CSRF context processor is always enabled -- irrespective of the context_processors list in OPTIONS -- and cannot be disabled.