forked from orbit-oss/flask
Merge branch 'stable'
This commit is contained in:
commit
330123258e
20 changed files with 548 additions and 437 deletions
|
|
@ -96,10 +96,10 @@ is ambiguous.
|
|||
One Template Engine
|
||||
-------------------
|
||||
|
||||
Flask decides on one template engine: Jinja2. Why doesn't Flask have a
|
||||
Flask decides on one template engine: Jinja. Why doesn't Flask have a
|
||||
pluggable template engine interface? You can obviously use a different
|
||||
template engine, but Flask will still configure Jinja2 for you. While
|
||||
that limitation that Jinja2 is *always* configured will probably go away,
|
||||
template engine, but Flask will still configure Jinja for you. While
|
||||
that limitation that Jinja is *always* configured will probably go away,
|
||||
the decision to bundle one template engine and use that will not.
|
||||
|
||||
Template engines are like programming languages and each of those engines
|
||||
|
|
@ -107,7 +107,7 @@ has a certain understanding about how things work. On the surface they
|
|||
all work the same: you tell the engine to evaluate a template with a set
|
||||
of variables and take the return value as string.
|
||||
|
||||
But that's about where similarities end. Jinja2 for example has an
|
||||
But that's about where similarities end. Jinja for example has an
|
||||
extensive filter system, a certain way to do template inheritance,
|
||||
support for reusable blocks (macros) that can be used from inside
|
||||
templates and also from Python code, supports iterative template
|
||||
|
|
@ -118,8 +118,8 @@ other hand treats templates similar to Python modules.
|
|||
|
||||
When it comes to connecting a template engine with an application or
|
||||
framework there is more than just rendering templates. For instance,
|
||||
Flask uses Jinja2's extensive autoescaping support. Also it provides
|
||||
ways to access macros from Jinja2 templates.
|
||||
Flask uses Jinja's extensive autoescaping support. Also it provides
|
||||
ways to access macros from Jinja templates.
|
||||
|
||||
A template abstraction layer that would not take the unique features of
|
||||
the template engines away is a science on its own and a too large
|
||||
|
|
@ -150,7 +150,7 @@ authentication technologies, and more. Flask may be "micro", but it's ready for
|
|||
production use on a variety of needs.
|
||||
|
||||
Why does Flask call itself a microframework and yet it depends on two
|
||||
libraries (namely Werkzeug and Jinja2). Why shouldn't it? If we look
|
||||
libraries (namely Werkzeug and Jinja). Why shouldn't it? If we look
|
||||
over to the Ruby side of web development there we have a protocol very
|
||||
similar to WSGI. Just that it's called Rack there, but besides that it
|
||||
looks very much like a WSGI rendition for Ruby. But nearly all
|
||||
|
|
@ -208,7 +208,7 @@ What Flask is, What Flask is Not
|
|||
|
||||
Flask will never have a database layer. It will not have a form library
|
||||
or anything else in that direction. Flask itself just bridges to Werkzeug
|
||||
to implement a proper WSGI application and to Jinja2 to handle templating.
|
||||
to implement a proper WSGI application and to Jinja to handle templating.
|
||||
It also binds to a few common standard library packages such as logging.
|
||||
Everything else is up for extensions.
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ debug environments with profilers and other things you might have enabled.
|
|||
Streaming from Templates
|
||||
------------------------
|
||||
|
||||
The Jinja2 template engine supports rendering a template piece by
|
||||
The Jinja template engine supports rendering a template piece by
|
||||
piece, returning an iterator of strings. Flask provides the
|
||||
:func:`~flask.stream_template` and :func:`~flask.stream_template_string`
|
||||
functions to make this easier to use.
|
||||
|
|
|
|||
|
|
@ -99,7 +99,7 @@ WTForm's field function, which renders the field for us. The keyword
|
|||
arguments will be inserted as HTML attributes. So, for example, you can
|
||||
call ``render_field(form.username, class='username')`` to add a class to
|
||||
the input element. Note that WTForms returns standard Python strings,
|
||||
so we have to tell Jinja2 that this data is already HTML-escaped with
|
||||
so we have to tell Jinja that this data is already HTML-escaped with
|
||||
the ``|safe`` filter.
|
||||
|
||||
Here is the :file:`register.html` template for the function we used above, which
|
||||
|
|
|
|||
|
|
@ -139,18 +139,16 @@ how you're using untrusted data.
|
|||
|
||||
.. code-block:: python
|
||||
|
||||
from flask import request
|
||||
from markupsafe import escape
|
||||
|
||||
@app.route("/<name>")
|
||||
def hello(name):
|
||||
@app.route("/hello")
|
||||
def hello():
|
||||
name = request.args.get("name", "Flask")
|
||||
return f"Hello, {escape(name)}!"
|
||||
|
||||
If a user managed to submit the name ``<script>alert("bad")</script>``,
|
||||
escaping causes it to be rendered as text, rather than running the
|
||||
script in the user's browser.
|
||||
|
||||
``<name>`` in the route captures a value from the URL and passes it to
|
||||
the view function. These variable rules are explained below.
|
||||
If a user submits ``/hello?name=<script>alert("bad")</script>``, escaping causes
|
||||
it to be rendered as text, rather than running the script in the user's browser.
|
||||
|
||||
|
||||
Routing
|
||||
|
|
@ -354,7 +352,7 @@ Rendering Templates
|
|||
|
||||
Generating HTML from within Python is not fun, and actually pretty
|
||||
cumbersome because you have to do the HTML escaping on your own to keep
|
||||
the application secure. Because of that Flask configures the `Jinja2
|
||||
the application secure. Because of that Flask configures the `Jinja
|
||||
<https://palletsprojects.com/p/jinja/>`_ template engine for you automatically.
|
||||
|
||||
Templates can be used to generate any type of text file. For web applications, you'll
|
||||
|
|
@ -394,8 +392,8 @@ package it's actually inside your package:
|
|||
/templates
|
||||
/hello.html
|
||||
|
||||
For templates you can use the full power of Jinja2 templates. Head over
|
||||
to the official `Jinja2 Template Documentation
|
||||
For templates you can use the full power of Jinja templates. Head over
|
||||
to the official `Jinja Template Documentation
|
||||
<https://jinja.palletsprojects.com/templates/>`_ for more information.
|
||||
|
||||
Here is an example template:
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ following example shows that process id 6847 is using port 5000.
|
|||
|
||||
macOS Monterey and later automatically starts a service that uses port
|
||||
5000. You can choose to disable this service instead of using a different port by
|
||||
searching for "AirPlay Receiver" in System Preferences and toggling it off.
|
||||
searching for "AirPlay Receiver" in System Settings and toggling it off.
|
||||
|
||||
|
||||
Deferred Errors on Reload
|
||||
|
|
|
|||
|
|
@ -1,21 +1,21 @@
|
|||
Templates
|
||||
=========
|
||||
|
||||
Flask leverages Jinja2 as its template engine. You are obviously free to use
|
||||
a different template engine, but you still have to install Jinja2 to run
|
||||
Flask leverages Jinja as its template engine. You are obviously free to use
|
||||
a different template engine, but you still have to install Jinja to run
|
||||
Flask itself. This requirement is necessary to enable rich extensions.
|
||||
An extension can depend on Jinja2 being present.
|
||||
An extension can depend on Jinja being present.
|
||||
|
||||
This section only gives a very quick introduction into how Jinja2
|
||||
This section only gives a very quick introduction into how Jinja
|
||||
is integrated into Flask. If you want information on the template
|
||||
engine's syntax itself, head over to the official `Jinja2 Template
|
||||
engine's syntax itself, head over to the official `Jinja Template
|
||||
Documentation <https://jinja.palletsprojects.com/templates/>`_ for
|
||||
more information.
|
||||
|
||||
Jinja Setup
|
||||
-----------
|
||||
|
||||
Unless customized, Jinja2 is configured by Flask as follows:
|
||||
Unless customized, Jinja is configured by Flask as follows:
|
||||
|
||||
- autoescaping is enabled for all templates ending in ``.html``,
|
||||
``.htm``, ``.xml``, ``.xhtml``, as well as ``.svg`` when using
|
||||
|
|
@ -25,13 +25,13 @@ Unless customized, Jinja2 is configured by Flask as follows:
|
|||
- a template has the ability to opt in/out autoescaping with the
|
||||
``{% autoescape %}`` tag.
|
||||
- Flask inserts a couple of global functions and helpers into the
|
||||
Jinja2 context, additionally to the values that are present by
|
||||
Jinja context, additionally to the values that are present by
|
||||
default.
|
||||
|
||||
Standard Context
|
||||
----------------
|
||||
|
||||
The following global variables are available within Jinja2 templates
|
||||
The following global variables are available within Jinja templates
|
||||
by default:
|
||||
|
||||
.. data:: config
|
||||
|
|
@ -237,7 +237,7 @@ strings. This can be used for streaming HTML in chunks to speed up
|
|||
initial page load, or to save memory when rendering a very large
|
||||
template.
|
||||
|
||||
The Jinja2 template engine supports rendering a template piece
|
||||
The Jinja template engine supports rendering a template piece
|
||||
by piece, returning an iterator of strings. Flask provides the
|
||||
:func:`~flask.stream_template` and :func:`~flask.stream_template_string`
|
||||
functions to make this easier to use.
|
||||
|
|
|
|||
|
|
@ -51,12 +51,12 @@ tags. For more information on that have a look at the Wikipedia article
|
|||
on `Cross-Site Scripting
|
||||
<https://en.wikipedia.org/wiki/Cross-site_scripting>`_.
|
||||
|
||||
Flask configures Jinja2 to automatically escape all values unless
|
||||
Flask configures Jinja to automatically escape all values unless
|
||||
explicitly told otherwise. This should rule out all XSS problems caused
|
||||
in templates, but there are still other places where you have to be
|
||||
careful:
|
||||
|
||||
- generating HTML without the help of Jinja2
|
||||
- generating HTML without the help of Jinja
|
||||
- calling :class:`~markupsafe.Markup` on data submitted by users
|
||||
- sending out HTML from uploaded files, never do that, use the
|
||||
``Content-Disposition: attachment`` header to prevent that problem.
|
||||
|
|
@ -65,7 +65,7 @@ careful:
|
|||
trick a browser to execute HTML.
|
||||
|
||||
Another thing that is very important are unquoted attributes. While
|
||||
Jinja2 can protect you from XSS issues by escaping HTML, there is one
|
||||
Jinja can protect you from XSS issues by escaping HTML, there is one
|
||||
thing it cannot protect you from: XSS by attribute injection. To counter
|
||||
this possible attack vector, be sure to always quote your attributes with
|
||||
either double or single quotes when using Jinja expressions in them:
|
||||
|
|
@ -158,7 +158,7 @@ recommend reviewing each of the headers below for use in your application.
|
|||
The `Flask-Talisman`_ extension can be used to manage HTTPS and the security
|
||||
headers for you.
|
||||
|
||||
.. _Flask-Talisman: https://github.com/GoogleCloudPlatform/flask-talisman
|
||||
.. _Flask-Talisman: https://github.com/wntrblm/flask-talisman
|
||||
|
||||
HTTP Strict Transport Security (HSTS)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -269,6 +269,27 @@ values (or any values that need secure signatures).
|
|||
.. _samesite_support: https://caniuse.com/#feat=same-site-cookie-attribute
|
||||
|
||||
|
||||
Host Header Validation
|
||||
----------------------
|
||||
|
||||
The ``Host`` header is used by the client to indicate what host name the request
|
||||
was made to. This is used, for example, by ``url_for(..., _external=True)`` to
|
||||
generate full URLs, for use in email or other messages outside the browser
|
||||
window.
|
||||
|
||||
By default the app doesn't know what host(s) it is allowed to be accessed
|
||||
through, and assumes any host is valid. Although browsers do not allow setting
|
||||
the ``Host`` header, requests made by attackers in other scenarios could set
|
||||
the ``Host`` header to a value they want.
|
||||
|
||||
When deploying your application, set :data:`TRUSTED_HOSTS` to restrict what
|
||||
values the ``Host`` header may be.
|
||||
|
||||
The ``Host`` header may be modified by proxies in between the client and your
|
||||
application. See :doc:`deploying/proxy_fix` to tell your app which proxy values
|
||||
to trust.
|
||||
|
||||
|
||||
Copy/Paste to Terminal
|
||||
----------------------
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue