@@ -677,6 +677,11 @@ see :doc:`/cookbook/security/form_login`.
677
677
for different firewalls. But usually for most applications, having one
678
678
main firewall is enough.
679
679
680
+ **5. Routing error pages are not covered by firewalls **
681
+
682
+ As Routing is done *before * security, Routing error pages are not covered
683
+ by any firewall.
684
+
680
685
Authorization
681
686
-------------
682
687
@@ -1000,73 +1005,6 @@ the user will be redirected to ``https``:
1000
1005
),
1001
1006
),
1002
1007
1003
- .. _book-security-securing-controller :
1004
-
1005
- Securing a Controller
1006
- ~~~~~~~~~~~~~~~~~~~~~
1007
-
1008
- Protecting your application based on URL patterns is easy, but may not be
1009
- fine-grained enough in certain cases. When necessary, you can easily force
1010
- authorization from inside a controller::
1011
-
1012
- // ...
1013
- use Symfony\Component\Security\Core\Exception\AccessDeniedException;
1014
-
1015
- public function helloAction($name)
1016
- {
1017
- if (false === $this->get('security.context')->isGranted('ROLE_ADMIN')) {
1018
- throw new AccessDeniedException();
1019
- }
1020
-
1021
- // ...
1022
- }
1023
-
1024
- .. _book-security-securing-controller-annotations :
1025
-
1026
- You can also choose to install and use the optional JMSSecurityExtraBundle,
1027
- which can secure your controller using annotations::
1028
-
1029
- // ...
1030
- use JMS\SecurityExtraBundle\Annotation\Secure;
1031
-
1032
- /**
1033
- * @Secure(roles="ROLE_ADMIN")
1034
- */
1035
- public function helloAction($name)
1036
- {
1037
- // ...
1038
- }
1039
-
1040
- For more information, see the `JMSSecurityExtraBundle `_ documentation.
1041
-
1042
- Securing other Services
1043
- ~~~~~~~~~~~~~~~~~~~~~~~
1044
-
1045
- In fact, anything in Symfony can be protected using a strategy similar to
1046
- the one seen in the previous section. For example, suppose you have a service
1047
- (i.e. a PHP class) whose job is to send emails from one user to another.
1048
- You can restrict use of this class - no matter where it's being used from -
1049
- to users that have a specific role.
1050
-
1051
- For more information on how you can use the Security component to secure
1052
- different services and methods in your application, see :doc: `/cookbook/security/securing_services `.
1053
-
1054
- Access Control Lists (ACLs): Securing Individual Database Objects
1055
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1056
-
1057
- Imagine you are designing a blog system where your users can comment on your
1058
- posts. Now, you want a user to be able to edit their own comments, but not
1059
- those of other users. Also, as the admin user, you yourself want to be able
1060
- to edit *all * comments.
1061
-
1062
- The Security component comes with an optional access control list (ACL) system
1063
- that you can use when you need to control access to individual instances
1064
- of an object in your system. *Without * ACL, you can secure your system so that
1065
- only certain users can edit blog comments in general. But *with * ACL, you
1066
- can restrict or allow access on a comment-by-comment basis.
1067
-
1068
- For more information, see the cookbook article: :doc: `/cookbook/security/acl `.
1069
-
1070
1008
Users
1071
1009
-----
1072
1010
@@ -1711,6 +1649,111 @@ In the above configuration, users with ``ROLE_ADMIN`` role will also have the
1711
1649
``ROLE_USER `` role. The ``ROLE_SUPER_ADMIN `` role has ``ROLE_ADMIN ``, ``ROLE_ALLOWED_TO_SWITCH ``
1712
1650
and ``ROLE_USER `` (inherited from ``ROLE_ADMIN ``).
1713
1651
1652
+ Access Control
1653
+ --------------
1654
+
1655
+ Now that you have Users and Roles, you can go further than URL patterns based authorization.
1656
+
1657
+ .. _book-security-securing-controller :
1658
+
1659
+ Access Control in Controllers
1660
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1661
+
1662
+ Protecting your application based on URL patterns is easy, but may not be
1663
+ fine-grained enough in certain cases. When necessary, you can easily force
1664
+ authorization from inside a controller::
1665
+
1666
+ // ...
1667
+ use Symfony\Component\Security\Core\Exception\AccessDeniedException;
1668
+
1669
+ public function helloAction($name)
1670
+ {
1671
+ if (false === $this->get('security.context')->isGranted('ROLE_ADMIN')) {
1672
+ throw new AccessDeniedException();
1673
+ }
1674
+
1675
+ // ...
1676
+ }
1677
+
1678
+ .. caution ::
1679
+
1680
+ A firewall must be active or an exception will be thrown when the ``isGranted() ``
1681
+ method is called. It's almost always a good idea to have a main firewall that
1682
+ covers all URLs (as it has been shown in this chapter).
1683
+
1684
+ .. _book-security-securing-controller-annotations :
1685
+
1686
+ You can also choose to install and use the optional `JMSSecurityExtraBundle `_,
1687
+ which can secure your controller using annotations::
1688
+
1689
+ // ...
1690
+ use JMS\SecurityExtraBundle\Annotation\Secure;
1691
+
1692
+ /**
1693
+ * @Secure(roles="ROLE_ADMIN")
1694
+ */
1695
+ public function helloAction($name)
1696
+ {
1697
+ // ...
1698
+ }
1699
+
1700
+ Access Control in Other Services
1701
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1702
+
1703
+ In fact, anything in Symfony can be protected using a strategy similar to
1704
+ the one seen in the previous section. For example, suppose you have a service
1705
+ (i.e. a PHP class) whose job is to send emails from one user to another.
1706
+ You can restrict use of this class - no matter where it's being used from -
1707
+ to users that have a specific role.
1708
+
1709
+ For more information on how you can use the Security component to secure
1710
+ different services and methods in your application, see :doc: `/cookbook/security/securing_services `.
1711
+
1712
+ .. _book-security-template :
1713
+
1714
+ Access Control in Templates
1715
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
1716
+
1717
+ If you want to check if the current user has a role inside a template, use
1718
+ the built-in helper function:
1719
+
1720
+ .. configuration-block ::
1721
+
1722
+ .. code-block :: html+jinja
1723
+
1724
+ {% if is_granted('ROLE_ADMIN') %}
1725
+ <a href="...">Delete</a>
1726
+ {% endif %}
1727
+
1728
+ .. code-block :: html+php
1729
+
1730
+ <?php if ($view['security']->isGranted('ROLE_ADMIN')): ?>
1731
+ <a href="...">Delete</a>
1732
+ <?php endif; ?>
1733
+
1734
+ .. note ::
1735
+
1736
+ If you use this function and are *not * at a URL behind a firewall
1737
+ active, an exception will be thrown. Again, it's almost always a good
1738
+ idea to have a main firewall that covers all URLs (as has been shown
1739
+ in this chapter).
1740
+
1741
+ Access Control Lists (ACLs): Securing Individual Database Objects
1742
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1743
+
1744
+ Imagine you are designing a blog system where your users can comment on your
1745
+ posts. Now, you want a user to be able to edit their own comments, but not
1746
+ those of other users. Also, as the admin user, you yourself want to be able
1747
+ to edit *all * comments.
1748
+
1749
+ The Security component comes with an optional access control list (ACL) system
1750
+ that you can use when you need to control access to individual instances
1751
+ of an object in your system. *Without * ACL, you can secure your system so that
1752
+ only certain users can edit blog comments in general. But *with * ACL, you
1753
+ can restrict or allow access on a comment-by-comment basis.
1754
+
1755
+ For more information, see the cookbook article: :doc: `/cookbook/security/acl `.
1756
+
1714
1757
Logging Out
1715
1758
-----------
1716
1759
@@ -1822,57 +1865,6 @@ is defined by the ``target`` parameter above (e.g. the ``homepage``). For
1822
1865
more information on configuring the logout, see the
1823
1866
:doc: `Security Configuration Reference </reference/configuration/security >`.
1824
1867
1825
- .. _book-security-template :
1826
-
1827
- Access Control in Templates
1828
- ---------------------------
1829
-
1830
- If you want to check if the current user has a role inside a template, use
1831
- the built-in helper function:
1832
-
1833
- .. configuration-block ::
1834
-
1835
- .. code-block :: html+jinja
1836
-
1837
- {% if is_granted('ROLE_ADMIN') %}
1838
- <a href="...">Delete</a>
1839
- {% endif %}
1840
-
1841
- .. code-block :: html+php
1842
-
1843
- <?php if ($view['security']->isGranted('ROLE_ADMIN')): ?>
1844
- <a href="...">Delete</a>
1845
- <?php endif; ?>
1846
-
1847
- .. note ::
1848
-
1849
- If you use this function and are *not * at a URL where there is a firewall
1850
- active, an exception will be thrown. Again, it's almost always a good
1851
- idea to have a main firewall that covers all URLs (as has been shown
1852
- in this chapter).
1853
-
1854
- Access Control in Controllers
1855
- -----------------------------
1856
-
1857
- If you want to check if the current user has a role in your controller, use
1858
- the :method: `Symfony\\ Component\\ Security\\ Core\\ SecurityContext::isGranted `
1859
- method of the security context::
1860
-
1861
- public function indexAction()
1862
- {
1863
- // show different content to admin users
1864
- if ($this->get('security.context')->isGranted('ROLE_ADMIN')) {
1865
- // ... load admin content here
1866
- }
1867
-
1868
- // ... load other regular content here
1869
- }
1870
-
1871
- .. note ::
1872
-
1873
- A firewall must be active or an exception will be thrown when the ``isGranted ``
1874
- method is called. See the note above about templates for more details.
1875
-
1876
1868
Impersonating a User
1877
1869
--------------------
1878
1870
0 commit comments