minor #16282 Correct spelling & grammar in 4.4 security/ (gnito-org)

This PR was merged into the 4.4 branch.

Discussion
----------

Correct spelling & grammar in 4.4 security/

<!--

If your pull request fixes a BUG, use the oldest maintained branch that contains
the bug (see https://symfony.com/releases for the list of maintained branches).

If your pull request documents a NEW FEATURE, use the same Symfony branch where
the feature was introduced (and `5.x` for features of unreleased versions).

-->

Commits
-------

f059582 Correct spelling & grammar in 4.4 security/

Author: javiereguiluz

security/custom_authentication_provider.rst

@@ -31,7 +31,7 @@ provider for WSSE authentication. The security protocol for WSSE provides
 several security benefits:
 
 #. Username / Password encryption
-#. Safe guarding against replay attacks
+#. Safeguarding against replay attacks
 #. No web server configuration required
 
 WSSE is very useful for the securing of web services, may they be SOAP or
@@ -147,7 +147,7 @@ set an authenticated token in the token storage if successful::
             } catch (AuthenticationException $failed) {
                 // ... you might log something here
 
-                // To deny the authentication clear the token. This will redirect to the login page.
+                // To deny the authentication, clear the token. This will redirect to the login page.
                 // Make sure to only clear your token, not those of other authentication listeners.
                 // $token = $this->tokenStorage->getToken();
                 // if ($token instanceof WsseUserToken && $this->providerKey === $token->getProviderKey()) {
@@ -372,8 +372,8 @@ a firewall in your security configuration.
     You may be wondering "why do you need a special factory class to add listeners
     and providers to the dependency injection container?". This is a very
     good question. The reason is you can use your firewall multiple times,
-    to secure multiple parts of your application. Because of this, each
-    time your firewall is used, a new service is created in the DI container.
+    to secure multiple parts of your application. Because of this, when
+    your firewall is used, a new service is created in the DI container.
     The factory is what creates these new services.
 
 Configuration

security/form_login_setup.rst

@@ -463,7 +463,7 @@ deal with this low level session variable. However, the
 can be used to read (like in the example above) or set this value manually.
 
 When the user tries to access a restricted page, they are being redirected to
-the login page. At that point target path will be set. After a successful login,
+the login page. At that point the target path will be set. After a successful login,
 the user will be redirected to this previously set target path.
 
 If you also want to apply this behavior to public pages, you can create an

security/multiple_guard_authenticators.rst

@@ -13,7 +13,7 @@ Multiple Authenticators with Shared Entry Point
 Sometimes you want to offer your users different authentication mechanisms like
 a form login and a Facebook login while both entry points redirect the user to
 the same login page.
-However, in your configuration you have to explicitly say which entry point
+However, in your configuration you have to explicitly specify which entry point
 you want to use.
 
 This is how your security configuration can look in action:
@@ -85,7 +85,7 @@ Multiple Authenticators with Separate Entry Points
 
 However, there are use cases where you have authenticators that protect different
 parts of your application. For example, you have a login form that protects
-the secured area of your application front-end and API end points that are
+the secured area of your application front-end and API endpoints that are
 protected with API tokens. As you can only configure one entry point per firewall,
 the solution is to split the configuration into two separate firewalls:
 

security/password_migration.rst

@@ -135,7 +135,7 @@ password should be stored:
 * :ref:`When using Doctrine's entity user provider <upgrade-the-password-doctrine>`
 * :ref:`When using a custom user provider <upgrade-the-password-custom-provider>`
 
-After this, you're done and passwords are always hashed as secure as possible!
+After this, you're done and passwords are always hashed as securely as possible!
 
 .. _provide-the-password-guard:
 

security/voters.rst

@@ -28,7 +28,7 @@ example for voters.
 
     Take a look at the
     :doc:`authorization </components/security/authorization>`
-    article for an even deeper understanding on voters.
+    article for an even deeper understanding of voters.
 
 Here's how Symfony works with voters:
 All voters are called each time you use the ``isGranted()`` method on Symfony's