Commit e1b77238 authored by Baptiste Mispelon's avatar Baptiste Mispelon
Browse files

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

parent 00a0d3de

docs/ref/clickjacking.txt

+1 −1
Original line number Diff line number Diff line
@@ -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

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

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.



.. _clickjacking-prevention:

docs/ref/contrib/sites.txt

+1 −1
Original line number Diff line number Diff line
@@ -172,7 +172,7 @@ Getting the current domain for display 


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

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."



It'd be inefficient and redundant to implement this signup-processing code

docs/releases/1.4.6.txt

+1 −1
Original line number Diff line number Diff line
@@ -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)``

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

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

header and browsers seem to ignore JavaScript there.

docs/releases/1.4.txt

+1 −1
Original line number Diff line number Diff line
@@ -811,7 +811,7 @@ instance: 


  * 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

    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

    affected forms.

docs/releases/1.5.2.txt

+1 −1
Original line number Diff line number Diff line
@@ -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)``

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

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

header and browsers seem to ignore JavaScript there.