Fixed a whole bunch of small docs typos, errors, and ommissions.

Fixes #8358, #8396, #8724, #9043, #9128, #9247, #9267, #9267, #9375, #9409, #9414, #9416, #9446, #9454, #9464, #9503, #9518, #9533, #9657, #9658, #9683, #9733, #9771, #9835, #9836, #9837, #9897, #9906, #9912, #9945, #9986, #9992, #10055, #10084, #10091, #10145, #10245, #10257, #10309, #10358, #10359, #10424, #10426, #10508, #10531, #10551, #10635, #10637, #10656, #10658, #10690, #10699, #19528.

Thanks to all the respective authors of those tickets.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@10371 bcc190cf-cafb-0310-a4f2-bffc1f526a37

1 files changed, 26 insertions, 8 deletions

diff --git a/docs/topics/auth.txt b/docs/topics/auth.txt
index 15d0b39856..0fdf8b3a3b 100644
--- a/docs/topics/auth.txt
+++ b/docs/topics/auth.txt
@@ -208,9 +208,9 @@ Methods
 
     .. method:: models.User.has_perm(perm)
 
-        Returns ``True`` if the user has the specified permission, where perm
-        is in the format ``"package.codename"``. If the user is inactive, this
-        method will always return ``False``.
+        Returns ``True`` if the user has the specified permission, where perm is
+        in the format ``"<application name>.<lowercased model name>"``. If the
+        user is inactive, this method will always return ``False``.
 
     .. method:: models.User.has_perms(perm_list)
 
@@ -444,18 +444,18 @@ To indicate that this model is the user profile model for a given site, fill in
 the setting :setting:`AUTH_PROFILE_MODULE` with a string consisting of the
 following items, separated by a dot:
 
-1. The (normalized to lower-case) name of the application in which the user
-   profile model is defined (in other words, an all-lowercase version of the
+1. The name of the application (case sensitive) in which the user
+   profile model is defined (in other words, the
    name which was passed to :djadmin:`manage.py startapp <startapp>` to create
    the application).
 
-2. The (normalized to lower-case) name of the model class.
+2. The name of the model (not case sensitive) class.
 
 For example, if the profile model was a class named ``UserProfile`` and was
 defined inside an application named ``accounts``, the appropriate setting would
 be::
 
-    AUTH_PROFILE_MODULE = 'accounts.userprofile'
+    AUTH_PROFILE_MODULE = 'accounts.UserProfile'
 
 When a user profile model has been defined and specified in this manner, each
 :class:`~django.contrib.auth.models.User` object will have a method --
@@ -779,7 +779,7 @@ In addition to the :func:`~views.login` view, the authentication system
 includes a few other useful built-in views located in
 :mod:`django.contrib.auth.views`:
 
-.. function:: views.logout(request, [next_page, template_name])
+.. function:: views.logout(request, [next_page, template_name, redirect_field_name])
 
     Logs a user out.
 
@@ -790,6 +790,10 @@ includes a few other useful built-in views located in
         * ``template_name``: The full name of a template to display after
           logging the user out. This will default to
           :file:`registration/logged_out.html` if no argument is supplied.
+          
+        * ``redirect_field_name``: The name of a ``GET`` field containing the
+          URL to redirect to after log out. Overrides ``next_page`` if the given
+          ``GET`` parameter is passed.
 
     **Template context:**
 
@@ -1017,6 +1021,10 @@ The permission_required decorator
             # ...
         my_view = permission_required('polls.can_vote')(my_view)
 
+    As for the :meth:`User.has_perm` method, permission names take the form
+    ``"<application name>.<lowercased model name>"`` (i.e. ``polls.choice`` for
+    a ``Choice`` model in the ``polls`` application).
+
     Note that :func:`~django.contrib.auth.decorators.permission_required()`
     also takes an optional ``login_url`` parameter. Example::
 
@@ -1332,6 +1340,16 @@ The order of :setting:`AUTHENTICATION_BACKENDS` matters, so if the same
 username and password is valid in multiple backends, Django will stop
 processing at the first positive match.
 
+.. note::
+
+    Once a user has authenticated, Django stores which backend was used to
+    authenticate the user in the user's session, and re-uses the same backend
+    for subsequent authentication attempts for that user. This effectively means
+    that authentication sources are cached, so if you change
+    :setting:`AUTHENTICATION_BACKENDS`, you'll need to clear out session data if
+    you need to force users to re-authenticate using different methods. A simple
+    way to do that is simply to execute ``Session.objects.all().delete()``.
+
 Writing an authentication backend
 ---------------------------------