diff --git a/docs/ref/clickjacking.txt b/docs/ref/clickjacking.txt index 0b81243b92f..cb3ac1bcd1b 100644 --- a/docs/ref/clickjacking.txt +++ b/docs/ref/clickjacking.txt @@ -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: diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt index fd2e917c1d9..225475803fc 100644 --- a/docs/ref/contrib/sites.txt +++ b/docs/ref/contrib/sites.txt @@ -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 diff --git a/docs/releases/1.4.6.txt b/docs/releases/1.4.6.txt index 3847ea26f94..e3ccbbb344a 100644 --- a/docs/releases/1.4.6.txt +++ b/docs/releases/1.4.6.txt @@ -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. diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt index 0bd1da0ef86..1ba2c6ac7fe 100644 --- a/docs/releases/1.4.txt +++ b/docs/releases/1.4.txt @@ -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. diff --git a/docs/releases/1.5.2.txt b/docs/releases/1.5.2.txt index 20771365aa8..2a2cf9195d1 100644 --- a/docs/releases/1.5.2.txt +++ b/docs/releases/1.5.2.txt @@ -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. diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt index b336bf46695..c514978f574 100644 --- a/docs/topics/http/sessions.txt +++ b/docs/topics/http/sessions.txt @@ -166,7 +166,7 @@ and the :setting:`SECRET_KEY` setting. 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 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 be detected as 'stale' if they are older than your :setting:`SESSION_COOKIE_AGE`.