[2.0.x] Fixed #28741 -- Removed unnecessary leading dot from cross-domain cookie examples.

Backport of afd375fc343baa46e61036087bc43b3d096bb0ca from master

3 files changed, 9 insertions, 10 deletions

diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
index 9eafd1b10a..c7c6d450a3 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -754,10 +754,9 @@ Methods
       in UTC. If ``expires`` is a ``datetime`` object, the ``max_age``
       will be calculated.
     * Use ``domain`` if you want to set a cross-domain cookie. For example,
-      ``domain=".lawrence.com"`` will set a cookie that is readable by
-      the domains www.lawrence.com, blogs.lawrence.com and
-      calendars.lawrence.com. Otherwise, a cookie will only be readable by
-      the domain that set it.
+      ``domain="example.com"`` will set a cookie that is readable by the
+      domains www.example.com, blog.example.com, etc. Otherwise, a cookie will
+      only be readable by the domain that set it.
     * Use ``httponly=True`` if you want to prevent client-side
       JavaScript from having access to the cookie.
 
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 90e6d1fe7c..5c530b7a04 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -317,7 +317,7 @@ Default: ``None``
 The domain to be used when setting the CSRF cookie.  This can be useful for
 easily allowing cross-subdomain requests to be excluded from the normal cross
 site request forgery protection.  It should be set to a string such as
-``".example.com"`` to allow a POST request from a form on one subdomain to be
+``"example.com"`` to allow a POST request from a form on one subdomain to be
 accepted by a view served from another subdomain.
 
 Please note that the presence of this setting does not imply that Django's CSRF
@@ -1756,8 +1756,8 @@ The age of the language cookie, in seconds.
 Default: ``None``
 
 The domain to use for the language cookie. Set this to a string such as
-``".example.com"`` (note the leading dot!) for cross-domain cookies, or use
-``None`` for a standard domain cookie.
+``"example.com"`` for cross-domain cookies, or use ``None`` for a standard
+domain cookie.
 
 Be cautious when updating this setting on a production site. If you update
 this setting to enable cross-domain cookies on a site that previously used
@@ -3002,8 +3002,8 @@ The age of session cookies, in seconds.
 Default: ``None``
 
 The domain to use for session cookies. Set this to a string such as
-``".example.com"`` (note the leading dot!) for cross-domain cookies, or use
-``None`` for a standard domain cookie.
+``"example.com"`` for cross-domain cookies, or use ``None`` for a standard
+domain cookie.
 
 Be cautious when updating this setting on a production site. If you update
 this setting to enable cross-domain cookies on a site that previously used
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index 2112926cc0..ce5d8019bd 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -653,7 +653,7 @@ 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.
 
 Another possible attack would be if ``good.example.com`` sets its
-:setting:`SESSION_COOKIE_DOMAIN` to ``".example.com"`` which would cause
+:setting:`SESSION_COOKIE_DOMAIN` to ``"example.com"`` which would cause
 session cookies from that site to be sent to ``bad.example.com``.
 
 Technical details