From 427b8a14e1916f28a3e5f952ac815e1c5d26870f Mon Sep 17 00:00:00 2001 From: Philipp Rieber Date: Tue, 19 Nov 2013 07:11:13 +0100 Subject: [PATCH 1/3] fix typos, formatting, yaml code blocks --- cookbook/configuration/pdo_session_storage.rst | 2 +- cookbook/form/dynamic_form_modification.rst | 2 +- cookbook/profiler/matchers.rst | 2 +- cookbook/security/acl_advanced.rst | 10 +++++----- cookbook/security/custom_authentication_provider.rst | 4 ++-- cookbook/security/custom_provider.rst | 2 +- cookbook/security/entity_provider.rst | 2 +- cookbook/security/target_path.rst | 2 +- cookbook/security/voters.rst | 2 +- cookbook/session/locale_sticky_session.rst | 4 ++-- cookbook/testing/http_authentication.rst | 2 +- cookbook/testing/insulating_clients.rst | 4 ++-- cookbook/testing/simulating_authentication.rst | 6 +++--- 13 files changed, 22 insertions(+), 22 deletions(-) diff --git a/cookbook/configuration/pdo_session_storage.rst b/cookbook/configuration/pdo_session_storage.rst index a6821ea95f9..1ce497083e8 100644 --- 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 index ff14372d822..d327aceeaa5 100644 --- 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 index 7216a7067ce..85941701ad9 100644 --- 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 index e04ab11ea90..acde19ea90d 100644 --- a/cookbook/security/acl_advanced.rst +++ b/cookbook/security/acl_advanced.rst @@ -53,8 +53,8 @@ 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: ``RoleSecurityIdentity`` and ``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 +173,12 @@ 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 +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. -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 index fecda563aed..dcce5113e93 100644 --- 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 index 6d1dbfc51b2..1e015454a4e 100644 --- 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 index 2b27612cabe..ea0171ec024 100644 --- 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 index 4d2d717c57f..587547d2345 100644 --- 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 index d94177f3365..fc93f10d667 100644 --- 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 index 48f27c477b0..0a95b465506 100644 --- 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 `. diff --git a/cookbook/testing/http_authentication.rst b/cookbook/testing/http_authentication.rst index cbb9c86a9fb..d6db89a8873 100644 --- 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 index 3411968eb80..fa91e591813 100644 --- 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 index 1be4eda5536..b67365398b3 100644 --- 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. From 1eb47fd9ee4f55c5506ef23a74fd06a23cafe89c Mon Sep 17 00:00:00 2001 From: Philipp Rieber Date: Tue, 19 Nov 2013 10:39:55 +0100 Subject: [PATCH 2/3] add API links --- cookbook/security/acl_advanced.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/cookbook/security/acl_advanced.rst b/cookbook/security/acl_advanced.rst index acde19ea90d..7cdf19d1c03 100644 --- a/cookbook/security/acl_advanced.rst +++ b/cookbook/security/acl_advanced.rst @@ -53,7 +53,9 @@ 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``. + 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 From 4c14bdbe0fc9ddb04d7f1e9d1c4d624c3c0b6514 Mon Sep 17 00:00:00 2001 From: Philipp Rieber Date: Tue, 19 Nov 2013 10:44:15 +0100 Subject: [PATCH 3/3] add API links --- cookbook/security/acl_advanced.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/cookbook/security/acl_advanced.rst b/cookbook/security/acl_advanced.rst index 7cdf19d1c03..1bc217d8e6e 100644 --- a/cookbook/security/acl_advanced.rst +++ b/cookbook/security/acl_advanced.rst @@ -175,9 +175,10 @@ 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,