- Added manual index entries to generated index.

1 files changed, 50 insertions, 0 deletions

diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index 0d1e3295d..36469def0 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -12,6 +12,9 @@ appropriate level of access with respect to a specific
 Authorization is enabled by modifying your application to include a
 :term:`authentication policy` and :term:`authorization policy`.
 
+.. index::
+   pair: enabling; authorization policy
+
 Enabling an Authorization Policy Imperatively
 ---------------------------------------------
 
@@ -62,6 +65,9 @@ It is also possible to construct your own custom authentication policy
 or authorization policy: see :ref:`creating_an_authentication_policy`
 and :ref:`creating_an_authorization_policy`.
 
+.. index::
+   triple: enabling; authorization policy; via ZCML
+
 Enabling an Authorization Policy Via ZCML
 -----------------------------------------
 
@@ -103,6 +109,10 @@ authentication policy ZCML directives that should prove useful.  See
 :ref:`authentication_policies_directives_section` and
 :ref:`authorization_policies_directives_section` for more information.
 
+.. index::
+   single: permissions
+   single: protecting views
+
 Protecting Views with Permissions
 ---------------------------------
 
@@ -146,6 +156,9 @@ Permission names are usually just strings.  They hold no special
 significance to the system.  You can name permissions whatever you
 like.
 
+.. index::
+   pair: assigning; ACL
+
 .. _assigning_acls:
 
 Assigning ACLs to your Model Objects
@@ -201,6 +214,9 @@ individual model instances with an ACL (as opposed to just decorating
 their class) in applications such as "CMS" systems where fine-grained
 access is required on an object-by-object basis.
 
+.. index::
+   single: ACE
+
 Elements of an ACL
 ------------------
 
@@ -287,6 +303,10 @@ view permission.  On the other hand, if you have an ACL like this:
 The authorization policy will deny Everyone the view permission, even
 though later in the ACL is an ACE that allows everyone.
 
+.. index::
+   single: prinicpal
+   pair: special; principal names
+
 Special Principal Names
 -----------------------
 
@@ -308,6 +328,9 @@ ACLs, e.g. :data:`repoze.bfg.security.Everyone`.
   This object is actually a string "under the hood"
   (``system.Authenticated``).
 
+.. index::
+   pair: special; permission names
+
 Special Permissions
 -------------------
 
@@ -325,6 +348,9 @@ module.  These can be imported for use in ACLs.
   known authorization policies, has the effect of indicating that a
   given principal "has" any permission asked for by the system.
 
+.. index::
+   pair: special; ACE
+
 Special ACEs
 ------------
 
@@ -352,6 +378,9 @@ authorization policy is in effect might look like so:
 
    __acl__ = [ (Allow, 'fred', 'view'), DENY_ALL ]
 
+.. index::
+   single: ACL inheritance
+
 ACL Inheritance
 ---------------
 
@@ -361,6 +390,9 @@ consulted for an ACL.  If that object does not have an ACL, *its*
 parent is consulted for an ACL, ad infinitum, until we've reached the
 root and there are no more parents left.
 
+.. index::
+   pair: location-aware; security
+
 Location-Awareness
 ------------------
 
@@ -384,6 +416,9 @@ root object's ``__parent__`` is ``None``.
 See :ref:`location_module` for documentations of functions which use
 location-awareness.  See also :ref:`location_aware`.
 
+.. index::
+   pair: forbidden view; changing
+
 Changing the Forbidden View
 ---------------------------
 
@@ -394,6 +429,9 @@ of the box", this forbidden view is very plain.  See
 instructions on how to create a custom forbidden view and arrange for
 it to be called when view authorization is denied.
 
+.. index::
+   pair: debugging; authorization failures
+
 .. _debug_authorization_section:
 
 Debugging View Authorization Failures
@@ -440,6 +478,9 @@ denied or allowed.  Introspecting this information in the debugger or
 via print statements when a call to
 :func:`repoze.bfg.security.has_permission` fails is often useful.
 
+.. index::
+   pair: ZCML directive; authentication policy
+
 .. _authentication_policies_directives_section:
 
 Built-In Authentication Policy ZCML Directives
@@ -516,6 +557,9 @@ An example of its usage, with all attributes fully expanded:
 See :ref:`repozewho1authenticationpolicy_directive` for detailed
 information.
 
+.. index::
+   pair: ZCML directive; authorization policy
+
 .. _authorization_policies_directives_section:
 
 Built-In Authorization Policy ZCML Directives
@@ -538,6 +582,9 @@ In other words, it has no configuration attributes; its existence in a
 
 See :ref:`aclauthorizationpolicy_directive` for detailed information.
 
+.. index::
+   pair: creating; authentication policy
+
 .. _creating_an_authentication_policy:
 
 Creating Your Own Authentication Policy
@@ -578,6 +625,9 @@ After you do so, you can pass an instance of such a class into the
 :class:`repoze.bfg.configuration.Configurator` class at configuration
 time as ``authentication_policy`` to use it.
 
+.. index::
+   pair: creating; authorization policy
+
 .. _creating_an_authorization_policy:
 
 Creating Your Own Authorization Policy