summaryrefslogtreecommitdiff
path: root/docs/narr/views.rst
diff options
context:
space:
mode:
authorChris McDonough <chrism@agendaless.com>2009-01-17 21:13:35 +0000
committerChris McDonough <chrism@agendaless.com>2009-01-17 21:13:35 +0000
commit041897caf1f765d0edffcc3a1af2787714f308ca (patch)
treefb4db3d622de017c955d588d23a0e3a1b072bcbb /docs/narr/views.rst
parenteff4620c56f38c32113cd452b18b8af8f8cd1bbd (diff)
downloadpyramid-041897caf1f765d0edffcc3a1af2787714f308ca.tar.gz
pyramid-041897caf1f765d0edffcc3a1af2787714f308ca.tar.bz2
pyramid-041897caf1f765d0edffcc3a1af2787714f308ca.zip
Security policy documentation.
Diffstat (limited to 'docs/narr/views.rst')
-rw-r--r--docs/narr/views.rst23
1 files changed, 15 insertions, 8 deletions
diff --git a/docs/narr/views.rst b/docs/narr/views.rst
index 5fa601a59..b23529f8f 100644
--- a/docs/narr/views.rst
+++ b/docs/narr/views.rst
@@ -266,10 +266,10 @@ Using Model Interfaces
----------------------
Instead of registering your views ``for`` a Python *class*, you can
-instead register a view for an :term:`interface`. Since an interface
-can be attached arbitrarily to any instance (as opposed to its
-identity being implied by only its class), associating a view with an
-interface can provide more flexibility for sharing a single view
+optionally register a view for an :term:`interface`. Since an
+interface can be attached arbitrarily to any instance (as opposed to
+its identity being implied by only its class), associating a view with
+an interface can provide more flexibility for sharing a single view
between two or more different implementations of a model type. For
example, if two model object instances of different Python class types
share the same interface, you can use the same view against each of
@@ -471,16 +471,23 @@ declaration:
/>
When a security policy is enabled, this view will be protected with
-the ``add`` permission. The view will not be called if the user does
-not possess the ``add`` permission relative to the current
-:term:`context`. Instead an HTTP ``Unauthorized`` status will be
-returned to the client.
+the ``add`` permission. The view will *not be called* if the user
+does not possess the ``add`` permission relative to the current
+:term:`context` and a security policy is enabled. Instead an HTTP
+``Unauthorized`` status will be returned to the client.
.. note::
See the :ref:`security_chapter` chapter to find out how to turn on
a security policy.
+.. note::
+
+ Packages such as :term:`repoze.who` are capable of intercepting an
+ ``Unauthorized`` response and displaying a form that asks a user to
+ authenticate. Use this kind of package to ask the user for
+ authentication credentials.
+
Using a View to Do A HTTP Redirect
----------------------------------