1024programmer Java How to write a Context processor in the Django framework

How to write a Context processor in the Django framework

Some suggestions for writing Context processor

Some suggestions for writing processors:

Make each context handler perform as small a function as possible. It’s easy to use multiple processors so you can break up functionality into logical chunks for future reuse.

Please note that the context processor in TEMPLATE_CONTEXT_PROCESSORS will be valid in every template based on this settings.py, so the naming of variables should not conflict with the variables of the template. Variable names are case-sensitive, so it is a good idea to use all uppercase letters for processor variables.

No matter which physical path they are stored in, as long as they are in your Python search path, you can point to them in the TEMPLATE_CONTEXT_PROCESSORS setting. It is recommended that you put them in a file named context_processors.py in the application or project directory.

html automatic translation

When generating HTML from a template, there is always a risk – variables may contain characters that will affect the resulting HTML. For example, consider this template fragment:

 Hello, {{ name }}.


At first, this may seem like a harmless way to display a username, but consider what would happen if the user entered a name like this:


With this username, the template will be rendered as:



This means that the browser will pop up a Javascript warning box!

Similarly, if the username contains a less than symbol, like this:


In that case the template result is translated like this:



The rest of the page becomes bold!

Obviously, user-submitted data should not be blindly trusted and inserted directly into your pages. Because a potentially malicious user can exploit such vulnerabilities to do bad things. This type of vulnerability is known as being exploited by cross-domain scripting (XSS). For more information on security, please see Chapter 20

To avoid this problem, you have two options:

First, you can ensure that every untrusted variable is processed by the escape filter to convert potentially harmful html characters into harmless ones. This was Django’s default approach for the first few years, but the problem with this is that it puts the onus on you (the developer, template author) to make sure everything is converted. It’s easy to forget about the data.

Second, you can use Django’s automatic HTML conversion. The remainder of this chapter describes how auto-context works.

By default in Django, each template automatically converts the output of each variable tag. Especially these five characters.

  • “\ “
  • System Message: WARNING/2 (, line 491); backlink
  • Inline literal start-string without end-string.
  • > is converted to >
  • ‘ (single quote) is converted to ‘
  • “(double quote) is converted to”
  • & is converted to &

Also, I would like to emphasize that this behavior is enabled by default. If you are using Django’s template system, you are protected.
How to turn it off

If you don’t want data to be automatically redirected, you have several ways to turn it off at the per-site level, per-template level, or per-variable level.

Why turn it off? Because sometimes template variables contain some raw html data, in which case we don’t want their content to be interpreted. For example, you might have a piece of trusted HTML stored in the database, and you want to embed it directly into your template. Or, you might be using Django’s template system to generate non-html text, such as an e-mail.
For individual variables

Use the safe filter to turn off automatic escaping for individual variables:

 This will be escaped: {{ data }}
 This will not be escaped: {{ data|safe }}


You can think of safe as shorthand for safe from further escaping, or as content that can be translated directly into HTML. In this example, if the data contains ”, the output will become:

 This will be escaped: 
 This will not be escaped: 


For template blocks

In order to control the automatic transition of the template, use the tag autoescape to wrap the entire template (or commonly used parts of the template), like this:

 {% autoescape off %}
  Hello {{ name }}


The autoescape tag has two parameters, on and off. Sometimes, you may want to prevent part of the automatic translation and automatically switch to another part. Here is an example of a template:

 Auto-escaping is on by default. Hello {{ name }}

 {% autoescape off %}
  This will not be auto-escaped: {{ data }}.

  Nor this: {{ other_data }}
  {% autoescape on %}
  Auto-escaping applies again: {{ name }}


Auto-escaping tagThe scope can not only affect the current template but also affect other tags through the include tag, just like the block tag. For example:


 {% autoescape off %}

{% block title %}{% endblock %}

{% block content %} {% endblock %} {%endautoescape%} # child.html {% extends "base.html" %} {% block title %}This & that{% endblock %} {% block content %}{{ greeting }}{% endblock %}

Since the automatic transition is turned off in the base template, the automatic transition is also turned off in the child template. Therefore, when the following HTML is submitted, the value of the greeting variable is the string Hello!


This & that



Usually, template authors don’t need to worry about automatic translation. Pyhton-based developers (writing VIEWS views and custom filters) only need to consider which data does not need to be translated, and mark the data in a timely manner to make them Work within the template.

If you are writing a template and don’t know whether to turn off automatic escaping, add an escape filter for all variables that need escaping. When auto-escape is on, using the escape filter may seem to escape the data twice, but there is no danger whatsoever. Because the escape filter does not work on escaped variables.

This article is from the internet and does not represent1024programmerPosition, please indicate the source when reprinting:https://www.1024programmer.com/787616

author: admin

Previous article
Next article

Leave a Reply

Your email address will not be published. Required fields are marked *

The latest and most comprehensive programming knowledge, all in 1024programmer.com

© 2023 1024programmer - Encyclopedia of Programming Field
Contact Us

Contact us


Online consultation: QQ交谈

E-mail: [email protected]

Working hours: Monday to Friday, 9:00-17:30, holidays off

Follow wechat
Scan wechat and follow us

Scan wechat and follow us