Merge branch '5.0' into 5.1

* 5.0:
  Update firewall.rst
  Update voters.rst
  Update authorization.rst
  Update authorization.rst

Author: javiereguiluz

components/security/authorization.rst

@@ -142,7 +142,7 @@ RoleVoter
 The :class:`Symfony\\Component\\Security\\Core\\Authorization\\Voter\\RoleVoter`
 supports attributes starting with ``ROLE_`` and grants access to the user
 when at least one required ``ROLE_*`` attribute can be found in the array of
-roles returned by the token's :method:`Symfony\\Component\\Security\\Core\\Authentication\\Token\\TokenInterface::getRoles`
+roles returned by the token's :method:`Symfony\\Component\\Security\\Core\\Authentication\\Token\\TokenInterface::getRoleNames`
 method::
 
     use Symfony\Component\Security\Core\Authorization\Voter\RoleVoter;
@@ -204,7 +204,7 @@ expressions have access to a number of
     $object = ...;
 
     $expression = new Expression(
-        '"ROLE_ADMIN" in roles or (not is_anonymous() and user.isSuperAdmin())'
+        '"ROLE_ADMIN" in role_names or (not is_anonymous() and user.isSuperAdmin())'
     )
 
     $vote = $expressionVoter->vote($token, $object, [$expression]);

components/security/firewall.rst

@@ -96,7 +96,7 @@ entry point and access denied URL, is provided by instances of the
 :class:`Symfony\\Bundle\\SecurityBundle\\Security\\FirewallConfig` class.
 
 This object can be accessed through the ``getFirewallConfig(Request $request)``
-method of the :class:`Symfony\\Component\\Security\\Http\\FirewallMap` class and
+method of the :class:`Symfony\\Bundle\\SecurityBundle\\Security\\FirewallMap` class and
 through the ``getConfig()``  method of the
 :class:`Symfony\\Bundle\\SecurityBundle\\Security\\FirewallContext` class.
 

security/voters.rst

@@ -118,7 +118,7 @@ would look like this::
         const VIEW = 'view';
         const EDIT = 'edit';
 
-        protected function supports($attribute, $subject)
+        protected function supports(string $attribute, $subject)
         {
             // if the attribute isn't one we support, return false
             if (!in_array($attribute, [self::VIEW, self::EDIT])) {
@@ -133,7 +133,7 @@ would look like this::
             return true;
         }
 
-        protected function voteOnAttribute($attribute, $subject, TokenInterface $token)
+        protected function voteOnAttribute(string $attribute, $subject, TokenInterface $token)
         {
             $user = $token->getUser();
 
@@ -178,7 +178,7 @@ That's it! The voter is done! Next, :ref:`configure it <declaring-the-voter-as-a
 
 To recap, here's what's expected from the two abstract methods:
 
-``Voter::supports($attribute, $subject)``
+``Voter::supports(string $attribute, $subject)``
     When ``isGranted()`` (or ``denyAccessUnlessGranted()``) is called, the first
     argument is passed here as ``$attribute`` (e.g. ``ROLE_USER``, ``edit``) and
     the second argument (if any) is passed as ``$subject`` (e.g. ``null``, a ``Post``
@@ -188,7 +188,7 @@ To recap, here's what's expected from the two abstract methods:
     return ``true`` if the attribute is ``view`` or ``edit`` and if the object is
     a ``Post`` instance.
 
-``voteOnAttribute($attribute, $subject, TokenInterface $token)``
+``voteOnAttribute(string $attribute, $subject, TokenInterface $token)``
     If you return ``true`` from ``supports()``, then this method is called. Your
     job is simple: return ``true`` to allow access and ``false`` to deny access.
     The ``$token`` can be used to find the current user object (if any). In this
@@ -231,7 +231,7 @@ with ``ROLE_SUPER_ADMIN``::
             $this->security = $security;
         }
 
-        protected function voteOnAttribute($attribute, $subject, TokenInterface $token)
+        protected function voteOnAttribute(string $attribute, $subject, TokenInterface $token)
         {
             // ...