p31829507
/
django
mirror of https://github.com/django/django.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Fixed some unnescesarily gendered language in the docs

This commit is contained in:
Alex Gaynor 2013-11-24 21:05:59 -06:00
parent eb38257e51
commit 4e07d93325
4 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/internals/git.txt
View File

@ -135,8 +135,8 @@ Feature-development branches
.. admonition:: Historical information .. admonition:: Historical information
Since Django moved to Git in 2012, anyone can clone the repository and Since Django moved to Git in 2012, anyone can clone the repository and
create his own branches, alleviating the need for official branches in the create their own branches, alleviating the need for official branches in
source code repository. the source code repository.
The following section is mostly useful if you're exploring the repository's The following section is mostly useful if you're exploring the repository's
history, for example if you're trying to understand how some features were history, for example if you're trying to understand how some features were

4
docs/topics/cache.txt
View File

@ -1027,8 +1027,8 @@ expose incorrect or sensitive data to subsequent visitors to those pages.
For example, say you operate a Web email system, and the contents of the For example, say you operate a Web email system, and the contents of the
"inbox" page obviously depend on which user is logged in. If an ISP blindly "inbox" page obviously depend on which user is logged in. If an ISP blindly
cached your site, then the first user who logged in through that ISP would have cached your site, then the first user who logged in through that ISP would have
his user-specific inbox page cached for subsequent visitors to the site. That's their user-specific inbox page cached for subsequent visitors to the site.
not cool. That's not cool.
Fortunately, HTTP provides a solution to this problem. A number of HTTP headers Fortunately, HTTP provides a solution to this problem. A number of HTTP headers
exist to instruct upstream caches to differ their cache contents depending on exist to instruct upstream caches to differ their cache contents depending on

6
docs/topics/http/sessions.txt
View File

@ -330,7 +330,7 @@ Before version 1.6, Django defaulted to using :mod:`pickle` to serialize
session data before storing it in the backend. If you're using the :ref:`signed session data before storing it in the backend. If you're using the :ref:`signed
cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is cookie session backend<cookie-session-backend>` and :setting:`SECRET_KEY` is
known by an attacker (there isn't an inherent vulnerability in Django that known by an attacker (there isn't an inherent vulnerability in Django that
would cause it to leak), the attacker could insert a string into his session would cause it to leak), the attacker could insert a string into their session
which, when unpickled, executes arbitrary code on the server. The technique for which, when unpickled, executes arbitrary code on the server. The technique for
doing so is simple and easily available on the internet. Although the cookie doing so is simple and easily available on the internet. Although the cookie
session storage signs the cookie-stored data to prevent tampering, a session storage signs the cookie-stored data to prevent tampering, a
@ -659,8 +659,8 @@ domain. This makes session fixation possible if all subdomains are not
controlled by trusted users (or, are at least unable to set cookies). controlled by trusted users (or, are at least unable to set cookies).
For example, an attacker could log into ``good.example.com`` and get a valid For example, an attacker could log into ``good.example.com`` and get a valid
session for his account. If the attacker has control over ``bad.example.com``, session for their account. If the attacker has control over ``bad.example.com``,
he can use it to send his session key to you since a subdomain is permitted they can use it to send their session key to you since a subdomain is permitted
to set cookies on ``*.example.com``. When you visit ``good.example.com``, to set cookies on ``*.example.com``. When you visit ``good.example.com``,
you'll be logged in as the attacker and might inadvertently enter your you'll be logged in as the attacker and might inadvertently enter your
sensitive personal data (e.g. credit card info) into the attackers account. sensitive personal data (e.g. credit card info) into the attackers account.

2
docs/topics/templates.txt
View File

@ -432,7 +432,7 @@ template fragment::
Hello, {{ name }}. Hello, {{ name }}.
At first, this seems like a harmless way to display a user's name, but consider At first, this seems like a harmless way to display a user's name, but consider
what would happen if the user entered his name as this:: what would happen if the user entered their name as this::
<script>alert('hello')</script> <script>alert('hello')</script>