mirror of
https://github.com/django/django.git
synced 2025-10-24 14:16:09 +00:00
Refs #36485 -- Removed double spaces after periods in sentences.
This commit is contained in:
@@ -4,7 +4,7 @@ How to authenticate using ``REMOTE_USER``
|
||||
|
||||
This document describes how to make use of external authentication sources
|
||||
(where the web server sets the ``REMOTE_USER`` environment variable) in your
|
||||
Django applications. This type of authentication solution is typically seen on
|
||||
Django applications. This type of authentication solution is typically seen on
|
||||
intranet sites, with single sign-on solutions such as IIS and Integrated
|
||||
Windows Authentication or Apache and `mod_authnz_ldap`_, `CAS`_, `WebAuth`_,
|
||||
`mod_auth_sspi`_, etc.
|
||||
@@ -15,9 +15,9 @@ Windows Authentication or Apache and `mod_authnz_ldap`_, `CAS`_, `WebAuth`_,
|
||||
.. _mod_auth_sspi: https://sourceforge.net/projects/mod-auth-sspi
|
||||
|
||||
When the web server takes care of authentication it typically sets the
|
||||
``REMOTE_USER`` environment variable for use in the underlying application. In
|
||||
``REMOTE_USER`` environment variable for use in the underlying application. In
|
||||
Django, ``REMOTE_USER`` is made available in the :attr:`request.META
|
||||
<django.http.HttpRequest.META>` attribute. Django can be configured to make
|
||||
<django.http.HttpRequest.META>` attribute. Django can be configured to make
|
||||
use of the ``REMOTE_USER`` value using the ``RemoteUserMiddleware``
|
||||
or ``PersistentRemoteUserMiddleware``, and
|
||||
:class:`~django.contrib.auth.backends.RemoteUserBackend` classes found in
|
||||
@@ -76,7 +76,7 @@ regardless of ``AUTHENTICATION_BACKENDS``.
|
||||
|
||||
If your authentication mechanism uses a custom HTTP header and not
|
||||
``REMOTE_USER``, you can subclass ``RemoteUserMiddleware`` and set the
|
||||
``header`` attribute to the desired ``request.META`` key. For example:
|
||||
``header`` attribute to the desired ``request.META`` key. For example:
|
||||
|
||||
.. code-block:: python
|
||||
:caption: ``mysite/middleware.py``
|
||||
|
||||
@@ -33,7 +33,7 @@ easier to follow, we'll use a consistent example throughout this document:
|
||||
wrapping a Python object representing the deal of cards in a hand of Bridge_.
|
||||
Don't worry, you don't have to know how to play Bridge to follow this example.
|
||||
You only need to know that 52 cards are dealt out equally to four players, who
|
||||
are traditionally called *north*, *east*, *south* and *west*. Our class looks
|
||||
are traditionally called *north*, *east*, *south* and *west*. Our class looks
|
||||
something like this::
|
||||
|
||||
class Hand:
|
||||
|
||||
@@ -264,7 +264,7 @@ Template filter code falls into one of two situations:
|
||||
reviewing your code.
|
||||
|
||||
Marking a filter ``is_safe`` will coerce the filter's return value to
|
||||
a string. If your filter should return a boolean or other non-string
|
||||
a string. If your filter should return a boolean or other non-string
|
||||
value, marking it ``is_safe`` will probably have unintended
|
||||
consequences (such as converting a boolean False to the string
|
||||
'False').
|
||||
@@ -841,7 +841,7 @@ When Django compiles a template, it splits the raw template text into *nodes*.
|
||||
Each node is an instance of ``django.template.Node`` and has a ``render()``
|
||||
method. A compiled template is a list of ``Node`` objects. When you call
|
||||
``render()`` on a compiled template object, the template calls ``render()`` on
|
||||
each ``Node`` in its node list, with the given context. The results are all
|
||||
each ``Node`` in its node list, with the given context. The results are all
|
||||
concatenated together to form the output of the template.
|
||||
|
||||
Thus, to define a custom template tag, you specify how the raw template tag is
|
||||
@@ -1159,7 +1159,7 @@ Now your tag should begin to look like this::
|
||||
return FormatTimeNode(date_to_be_formatted, format_string[1:-1])
|
||||
|
||||
You also have to change the renderer to retrieve the actual contents of the
|
||||
``date_updated`` property of the ``blog_entry`` object. This can be
|
||||
``date_updated`` property of the ``blog_entry`` object. This can be
|
||||
accomplished by using the ``Variable()`` class in ``django.template``.
|
||||
|
||||
To use the ``Variable`` class, instantiate it with the name of the variable to
|
||||
|
||||
@@ -3,7 +3,7 @@ How to manage static files (e.g. images, JavaScript, CSS)
|
||||
=========================================================
|
||||
|
||||
Websites generally need to serve additional files such as images, JavaScript,
|
||||
or CSS. In Django, we refer to these files as "static files". Django provides
|
||||
or CSS. In Django, we refer to these files as "static files". Django provides
|
||||
:mod:`django.contrib.staticfiles` to help you manage them.
|
||||
|
||||
This page describes how you can serve these static files.
|
||||
|
||||
Reference in New Issue
Block a user