symfony · weaverryan · Nov 27, 2013 · Nov 19, 2013 · Nov 19, 2013 · Nov 19, 2013
diff --git a/cookbook/configuration/pdo_session_storage.rst b/cookbook/configuration/pdo_session_storage.rst
@@ -16,7 +16,7 @@ configuration format of your choice):
 
 .. versionadded:: 2.1
     In Symfony2.1 the class and namespace are slightly modified. You can now
-    find the session storage classes in the `Session\\Storage` namespace:
+    find the session storage classes in the ``Session\\Storage`` namespace:
     ``Symfony\Component\HttpFoundation\Session\Storage``. Also
     note that in Symfony2.1 you should configure ``handler_id`` not ``storage_id`` like in Symfony2.0.
     Below, you'll notice that ``%session.storage.options%`` is not used anymore.

diff --git a/cookbook/form/dynamic_form_modification.rst b/cookbook/form/dynamic_form_modification.rst
@@ -348,7 +348,7 @@ it with :ref:`dic-tags-form-type`.
         services:
             acme.form.friend_message:
                 class: Acme\DemoBundle\Form\Type\FriendMessageFormType
-                arguments: [@security.context]
+                arguments: ["@security.context"]
                 tags:
                     -
                         name: form.type

diff --git a/cookbook/profiler/matchers.rst b/cookbook/profiler/matchers.rst
@@ -101,7 +101,7 @@ Then, you need to configure the service:
         services:
             acme_demo.profiler.matcher.super_admin:
                 class: "%acme_demo.profiler.matcher.super_admin.class%"
-                arguments: [@security.context]
+                arguments: ["@security.context"]
 
     .. code-block:: xml
 

diff --git a/cookbook/security/acl_advanced.rst b/cookbook/security/acl_advanced.rst
@@ -53,8 +53,10 @@ tables are ordered from least rows to most rows in a typical application:
 
 - *acl_security_identities*: This table records all security identities (SID)
   which hold ACEs. The default implementation ships with two security
-  identities: ``RoleSecurityIdentity``, and ``UserSecurityIdentity``
-- *acl_classes*: This table maps class names to a unique id which can be
+  identities:
+  :class:`Symfony\\Component\\Security\\Acl\\Domain\\RoleSecurityIdentity` and
+  :class:`Symfony\\Component\\Security\\Acl\\Domain\\UserSecurityIdentity`.
+- *acl_classes*: This table maps class names to a unique ID which can be
   referenced from other tables.
 - *acl_object_identities*: Each row in this table represents a single domain
   object instance.
@@ -173,12 +175,13 @@ Process for Reaching Authorization Decisions
 The ACL class provides two methods for determining whether a security identity
 has the required bitmasks, ``isGranted`` and ``isFieldGranted``. When the ACL
 receives an authorization request through one of these methods, it delegates
-this request to an implementation of PermissionGrantingStrategy. This allows
-you to replace the way access decisions are reached without actually modifying
-the ACL class itself.
+this request to an implementation of
+:class:`Symfony\\Component\\Security\\Acl\\Domain\\PermissionGrantingStrategy`.
+This allows you to replace the way access decisions are reached without actually
+modifying the ACL class itself.
 
-The PermissionGrantingStrategy first checks all your object-scope ACEs if none
-is applicable, the class-scope ACEs will be checked, if none is applicable,
+The ``PermissionGrantingStrategy`` first checks all your object-scope ACEs. If none
+is applicable, the class-scope ACEs will be checked. If none is applicable,
 then the process will be repeated with the ACEs of the parent ACL. If no
 parent ACL exists, an exception will be thrown.
 

diff --git a/cookbook/security/custom_authentication_provider.rst b/cookbook/security/custom_authentication_provider.rst
@@ -281,7 +281,7 @@ The Factory
 
 You have created a custom token, custom listener, and custom provider. Now
 you need to tie them all together. How do you make your provider available
-to your security configuration? The answer is by using a ``factory``. A factory
+to your security configuration? The answer is by using a *factory*. A factory
 is where you hook into the Security component, telling it the name of your
 provider and any configuration options available for it. First, you must
 create a class which implements
@@ -531,7 +531,7 @@ the ``addConfiguration`` method.
     }
 
 Now, in the ``create`` method of the factory, the ``$config`` argument will
-contain a 'lifetime' key, set to 5 minutes (300 seconds) unless otherwise
+contain a ``lifetime`` key, set to 5 minutes (300 seconds) unless otherwise
 set in the configuration. Pass this argument to your authentication provider
 in order to put it to use.
 

diff --git a/cookbook/security/custom_provider.rst b/cookbook/security/custom_provider.rst
@@ -280,7 +280,7 @@ users, e.g. by filling in a login form. You can do this by adding a line to the
 
 The value here should correspond with however the passwords were originally
 encoded when creating your users (however those users were created). When
-a user submits her password, the password is appended to the salt value and
+a user submits her password, the salt value is appended to the password and
 then encoded using this algorithm before being compared to the hashed password
 returned by your ``getPassword()`` method. Additionally, depending on your
 options, the password may be encoded multiple times and encoded to base64.

diff --git a/cookbook/security/entity_provider.rst b/cookbook/security/entity_provider.rst
@@ -258,7 +258,7 @@ then be checked against your User entity records in the database:
 
             role_hierarchy:
                 ROLE_ADMIN:       ROLE_USER
-                ROLE_SUPER_ADMIN: [ ROLE_USER, ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH ]
+                ROLE_SUPER_ADMIN: [ ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH ]
 
             providers:
                 administrators:

diff --git a/cookbook/security/target_path.rst b/cookbook/security/target_path.rst
@@ -19,7 +19,7 @@ class and override the default method named ``setTargetPath()``.
 
 First, override the ``security.exception_listener.class`` parameter in your
 configuration file. This can be done from your main configuration file (in
-`app/config`) or from a configuration file being imported from a bundle:
+``app/config``) or from a configuration file being imported from a bundle:
 
 .. configuration-block::
 

diff --git a/cookbook/security/voters.rst b/cookbook/security/voters.rst
@@ -114,7 +114,7 @@ Declaring the Voter as a Service
 --------------------------------
 
 To inject the voter into the security layer, you must declare it as a service,
-and tag it as a "security.voter":
+and tag it as a ``security.voter``:
 
 .. configuration-block::
 

diff --git a/cookbook/session/locale_sticky_session.rst b/cookbook/session/locale_sticky_session.rst
@@ -10,8 +10,8 @@ during a user's request. In this article, you'll learn how to make the locale
 of a user "sticky" so that once it's set, that same locale will be used for
 every subsequent request.
 
-Creating LocaleListener
------------------------
+Creating a LocaleListener
+-------------------------
 
 To simulate that the locale is stored in a session, you need to create and
 register a :doc:`new event listener </cookbook/service_container/event_listener>`.

diff --git a/cookbook/testing/http_authentication.rst b/cookbook/testing/http_authentication.rst
@@ -33,7 +33,7 @@ key in your firewall, along with the ``form_login`` key:
         security:
             firewalls:
                 your_firewall_name:
-                    http_basic:
+                    http_basic: ~
 
     .. code-block:: xml
 

diff --git a/cookbook/testing/insulating_clients.rst b/cookbook/testing/insulating_clients.rst
@@ -4,8 +4,8 @@
 How to test the Interaction of several Clients
 ==============================================
 
-If you need to simulate an interaction between different Clients (think of a
-chat for instance), create several Clients::
+If you need to simulate an interaction between different clients (think of a
+chat for instance), create several clients::
 
     $harry = static::createClient();
     $sally = static::createClient();

diff --git a/cookbook/testing/simulating_authentication.rst b/cookbook/testing/simulating_authentication.rst
@@ -12,7 +12,7 @@ One of the solutions is to configure your firewall to use ``http_basic`` in
 the test environment as explained in
 :doc:`/cookbook/testing/http_authentication`.
 Another way would be to create a token yourself and store it in a session.
-While doing this, you have to make sure that appropriate cookie is sent
+While doing this, you have to make sure that an appropriate cookie is sent
 with a request. The following example demonstrates this technique::
 
     // src/Acme/DemoBundle/Tests/Controller/DemoControllerTest.php
@@ -57,5 +57,5 @@ with a request. The following example demonstrates this technique::
 
 .. note::
 
-    The technique described in :doc:`/cookbook/testing/http_authentication`.
-    is cleaner and therefore preferred way.
+    The technique described in :doc:`/cookbook/testing/http_authentication`
+    is cleaner and therefore the preferred way.