Merge branch 'master' of github.com:Pylons/pyramid

3 files changed, 14 insertions, 9 deletions

diff --git a/docs/narr/renderers.rst b/docs/narr/renderers.rst
index 63287e2cd..1158d2225 100644
--- a/docs/narr/renderers.rst
+++ b/docs/narr/renderers.rst
@@ -329,7 +329,7 @@ time "by hand".  Configure a JSONP renderer using the
 Once this renderer is registered via
 :meth:`~pyramid.config.Configurator.add_renderer` as above, you can use
 ``jsonp`` as the ``renderer=`` parameter to ``@view_config`` or
-:meth:`pyramid.config.Configurator.add_view``:
+:meth:`pyramid.config.Configurator.add_view`:
 
 .. code-block:: python
 
diff --git a/docs/narr/security.rst b/docs/narr/security.rst
index 07ec0f21e..3a94b4f7d 100644
--- a/docs/narr/security.rst
+++ b/docs/narr/security.rst
@@ -92,11 +92,11 @@ For example:
    from pyramid.config import Configurator
    from pyramid.authentication import AuthTktAuthenticationPolicy
    from pyramid.authorization import ACLAuthorizationPolicy
-   authentication_policy = AuthTktAuthenticationPolicy('seekrit')
-   authorization_policy = ACLAuthorizationPolicy()
+   authn_policy = AuthTktAuthenticationPolicy('seekrit', hashalg='sha512')
+   authz_policy = ACLAuthorizationPolicy()
    config = Configurator()
-   config.set_authentication_policy(authentication_policy)
-   config.set_authorization_policy(authorization_policy)
+   config.set_authentication_policy(authn_policy)
+   config.set_authorization_policy(authz_policy)
 
 .. note:: the ``authentication_policy`` and ``authorization_policy``
    arguments may also be passed to their respective methods mentioned above
diff --git a/docs/narr/sessions.rst b/docs/narr/sessions.rst
index 1aa1b6341..f7da7838e 100644
--- a/docs/narr/sessions.rst
+++ b/docs/narr/sessions.rst
@@ -63,10 +63,15 @@ application by using the ``session_factory`` argument to the
    this implementation is, by default, *unencrypted*.  You should not use it
    when you keep sensitive information in the session object, as the
    information can be easily read by both users of your application and third
-   parties who have access to your users' network traffic.  Use a different
-   session factory implementation (preferably one which keeps session data on
-   the server) for anything but the most basic of applications where "session
-   security doesn't matter".
+   parties who have access to your users' network traffic.  And if you use this
+   sessioning implementation, and you inadvertently create a cross-site
+   scripting vulnerability in your application, because the session data is
+   stored unencrypted in a cookie, it will also be easier for evildoers to
+   obtain the current user's cross-site scripting token.  In short, use a
+   different session factory implementation (preferably one which keeps session
+   data on the server) for anything but the most basic of applications where
+   "session security doesn't matter", and you are sure your application has no
+   cross-site scripting vulnerabilities.
 
 .. index::
    single: session object