From 8c56ae41b6f0221d72f1a255ce1a3ac467b98d79 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Sun, 27 Dec 2009 22:47:08 +0000 Subject: - Added manual index entries to generated index. --- docs/narr/security.rst | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) (limited to 'docs/narr/security.rst') 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 -- cgit v1.2.3