p15693087
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Changed the doc to use gender-neutral pronouns when possible.

This commit is contained in:
Baptiste Mispelon 2013-10-02 16:41:04 +02:00
parent 00a0d3de02
commit e1b7723817
6 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/ref/clickjacking.txt
View File

@ -20,7 +20,7 @@ purchase an item. A user has chosen to stay logged into the store all the time
for convenience. An attacker site might create an "I Like Ponies" button on one for convenience. An attacker site might create an "I Like Ponies" button on one
of their own pages, and load the store's page in a transparent iframe such that of their own pages, and load the store's page in a transparent iframe such that
the "Buy Now" button is invisibly overlaid on the "I Like Ponies" button. If the the "Buy Now" button is invisibly overlaid on the "I Like Ponies" button. If the
user visits the attacker site and clicks "I Like Ponies" he will inadvertently user visits the attacker site and clicks "I Like Ponies" he or she will inadvertently
click on the online store's "Buy Now" button and unknowingly purchase the item. click on the online store's "Buy Now" button and unknowingly purchase the item.
.. _clickjacking-prevention: .. _clickjacking-prevention:

2
docs/ref/contrib/sites.txt
View File

@ -172,7 +172,7 @@ Getting the current domain for display
LJWorld.com and Lawrence.com both have email alert functionality, which lets LJWorld.com and Lawrence.com both have email alert functionality, which lets
readers sign up to get notifications when news happens. It's pretty basic: A readers sign up to get notifications when news happens. It's pretty basic: A
reader signs up on a Web form, and he immediately gets an email saying, reader signs up on a Web form, and he or she immediately gets an email saying,
"Thanks for your subscription." "Thanks for your subscription."
It'd be inefficient and redundant to implement this signup-processing code It'd be inefficient and redundant to implement this signup-processing code

2
docs/releases/1.4.6.txt
View File

@ -19,7 +19,7 @@ The security checks for these redirects (namely
``django.util.http.is_safe_url()``) didn't check if the scheme is ``http(s)`` ``django.util.http.is_safe_url()``) didn't check if the scheme is ``http(s)``
and as such allowed ``javascript:...`` URLs to be entered. If a developer and as such allowed ``javascript:...`` URLs to be entered. If a developer
relied on ``is_safe_url()`` to provide safe redirect targets and put such a relied on ``is_safe_url()`` to provide safe redirect targets and put such a
URL into a link, he could suffer from a XSS attack. This bug doesn't affect URL into a link, he or she could suffer from a XSS attack. This bug doesn't affect
Django currently, since we only put this URL into the ``Location`` response Django currently, since we only put this URL into the ``Location`` response
header and browsers seem to ignore JavaScript there. header and browsers seem to ignore JavaScript there.

2
docs/releases/1.4.txt
View File

@ -811,7 +811,7 @@ instance:
* Consequences: The user will see an error about the form having expired * Consequences: The user will see an error about the form having expired
and will be sent back to the first page of the wizard, losing the data and will be sent back to the first page of the wizard, losing the data
he has entered so far. he or she has entered so far.
* Time period: The amount of time you expect users to take filling out the * Time period: The amount of time you expect users to take filling out the
affected forms. affected forms.

2
docs/releases/1.5.2.txt
View File

@ -16,7 +16,7 @@ The security checks for these redirects (namely
``django.util.http.is_safe_url()``) didn't check if the scheme is ``http(s)`` ``django.util.http.is_safe_url()``) didn't check if the scheme is ``http(s)``
and as such allowed ``javascript:...`` URLs to be entered. If a developer and as such allowed ``javascript:...`` URLs to be entered. If a developer
relied on ``is_safe_url()`` to provide safe redirect targets and put such a relied on ``is_safe_url()`` to provide safe redirect targets and put such a
URL into a link, he could suffer from a XSS attack. This bug doesn't affect URL into a link, he or she could suffer from a XSS attack. This bug doesn't affect
Django currently, since we only put this URL into the ``Location`` response Django currently, since we only put this URL into the ``Location`` response
header and browsers seem to ignore JavaScript there. header and browsers seem to ignore JavaScript there.

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

@ -166,7 +166,7 @@ and the :setting:`SECRET_KEY` setting.
cookie backend might open you up to `replay attacks`_. Unlike other session cookie backend might open you up to `replay attacks`_. Unlike other session
backends which keep a server-side record of each session and invalidate it backends which keep a server-side record of each session and invalidate it
when a user logs out, cookie-based sessions are not invalidated when a user when a user logs out, cookie-based sessions are not invalidated when a user
logs out. Thus if an attacker steals a user's cookie, he can use that logs out. Thus if an attacker steals a user's cookie, he or she can use that
cookie to login as that user even if the user logs out. Cookies will only cookie to login as that user even if the user logs out. Cookies will only
be detected as 'stale' if they are older than your be detected as 'stale' if they are older than your
:setting:`SESSION_COOKIE_AGE`. :setting:`SESSION_COOKIE_AGE`.