Merge pull request #1825 from greg0ire/security_cookbook_pass

weaverryan · weaverryan · commit 7d6c0138fded · 2012-10-23T15:19:58.000-07:00
Security cookbook pass
diff --git a/cookbook/security/acl_advanced.rst b/cookbook/security/acl_advanced.rst
@@ -34,7 +34,7 @@ Object Identities
 The ACL system is completely decoupled from your domain objects. They don't
 even have to be stored in the same database, or on the same server. In order
 to achieve this decoupling, in the ACL system your objects are represented
-through object identity objects. Everytime, you want to retrieve the ACL for a
+through object identity objects. Everytime you want to retrieve the ACL for a
 domain object, the ACL system will first create an object identity from your
 domain object, and then pass this object identity to the ACL provider for
 further processing.
diff --git a/cookbook/security/custom_authentication_provider.rst b/cookbook/security/custom_authentication_provider.rst
@@ -489,7 +489,7 @@ Configuration
 ~~~~~~~~~~~~~
 
 You can add custom options under the ``wsse`` key in your security configuration.
-For instance, the time allowed before expiring the Created header item,
+For instance, the time allowed before expiring the ``Created`` header item,
 by default, is 5 minutes. Make this configurable, so different firewalls
 can have different timeout lengths.
 
diff --git a/cookbook/security/force_https.rst b/cookbook/security/force_https.rst
@@ -5,9 +5,9 @@ How to force HTTPS or HTTP for Different URLs
 =============================================
 
 You can force areas of your site to use the ``HTTPS`` protocol in the security
-config. This is done through the ``access_control`` rules using the ``requires_channel``
+config. This is done through the ``access_control`` rules, using the ``requires_channel``
 option. For example, if you want to force all URLs starting with ``/secure``
-to use ``HTTPS`` then you could use the following config:
+to use ``HTTPS`` then you could use the following configuration:
 
 .. configuration-block::
 
@@ -33,7 +33,7 @@ to use ``HTTPS`` then you could use the following config:
                 ),
             ),
 
-The login form itself needs to allow anonymous access otherwise users will
+The login form itself needs to allow anonymous access, otherwise users will
 be unable to authenticate. To force it to use ``HTTPS`` you can still use
 ``access_control`` rules by using the ``IS_AUTHENTICATED_ANONYMOUSLY`` 
 role:
diff --git a/cookbook/security/form_login.rst b/cookbook/security/form_login.rst
@@ -105,10 +105,11 @@ Redirecting after Success
 You can change where the login form redirects after a successful login using
 the various config options. By default the form will redirect to the URL the
 user requested (i.e. the URL which triggered the login form being shown).
-For example, if the user requested ``http://www.example.com/admin/post/18/edit``
-then after he/she will eventually be sent back to ``http://www.example.com/admin/post/18/edit`` 
-after successfully logging in. This is done by storing the requested URL
-in the session. If no URL is present in the session (perhaps the user went
+For example, if the user requested ``http://www.example.com/admin/post/18/edit``,
+then after they successfully logs in, they will eventually be sent back to
+``http://www.example.com/admin/post/18/edit``.
+This is done by storing the requested URL in the session.
+If no URL is present in the session (perhaps the user went
 directly to the login page), then the user is redirected to the default page,
 which is  ``/`` (i.e. the homepage) by default. You can change this behavior
 in several ways.
@@ -155,7 +156,7 @@ the following config:
             ),
         ));
 
-Now, when no URL is set in the session users will be sent to ``/admin``.
+Now, when no URL is set in the session, users will be sent to ``/admin``.
 
 Always Redirect to the Default Page
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -329,7 +330,7 @@ option to another value.
 Redirecting on Login Failure
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-In addition to redirect the user after a successful login, you can also set
+In addition to redirecting the user after a successful login, you can also set
 the URL that the user should be redirected to after a failed login (e.g. an
 invalid username or password was submitted). By default, the user is redirected
 back to the login form itself. You can set this to a different URL with the
