Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhanced Firewall Restrictions docs #3681

Merged
merged 1 commit into from
Mar 19, 2014
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion book/security.rst
Original file line number Diff line number Diff line change
Expand Up @@ -181,6 +181,11 @@ firewall is activated does *not* mean, however, that the HTTP authentication
username and password box is displayed for every URL. For example, any user
can access ``/foo`` without being prompted to authenticate.

.. tip::

You can also match a request against other details of the request (e.g. host, method). For more
information and examples read :doc:`/cookbook/security/firewall_restriction`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a little more explanatory:

... against other details of the request (e.g. host, method). For more ...


.. image:: /images/book/security_anonymous_user_access.png
:align: center

Expand Down Expand Up @@ -2139,7 +2144,7 @@ Learn more from the Cookbook
* :doc:`Blacklist users by IP address with a custom voter </cookbook/security/voters>`
* :doc:`Access Control Lists (ACLs) </cookbook/security/acl>`
* :doc:`/cookbook/security/remember_me`
* :doc:`How to Restrict Firewalls to a Specific Host </cookbook/security/host_restriction>`
* :doc:`How to Restrict Firewalls to a Specific Request </cookbook/security/firewall_restriction>`

.. _`FOSUserBundle`: https://github.com/FriendsOfSymfony/FOSUserBundle
.. _`implement the \Serializable interface`: http://php.net/manual/en/class.serializable.php
Expand Down
2 changes: 1 addition & 1 deletion cookbook/map.rst.inc
Original file line number Diff line number Diff line change
Expand Up @@ -138,7 +138,7 @@
* :doc:`/cookbook/security/acl`
* :doc:`/cookbook/security/acl_advanced`
* :doc:`/cookbook/security/force_https`
* :doc:`/cookbook/security/host_restriction`
* :doc:`/cookbook/security/firewall_restriction`
* :doc:`/cookbook/security/form_login`
* :doc:`/cookbook/security/securing_services`
* :doc:`/cookbook/security/custom_provider`
Expand Down
193 changes: 193 additions & 0 deletions cookbook/security/firewall_restriction.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,193 @@
.. index::
single: Security; Restrict Security Firewalls to a Request

How to Restrict Firewalls to a Specific Request
===============================================

When using the Security component, you can create firewalls that match certain request options.
In most cases, matching against the URL is sufficient, but in special cases you can further
restrict the initialization of a firewall against other options of the request.

.. note::

You can use any of these restrictions individually or mix them together to get
your desired firewall configuration.

Restricting by Pattern
----------------------

This is the default restriction and restricts a firewall to only be initialized if the request URL
matches the configured ``pattern``.

.. configuration-block::

.. code-block:: yaml
# app/config/security.yml
# ...
security:
firewalls:
secured_area:
pattern: ^/admin
# ...
.. code-block:: xml
<!-- app/config/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:srv="http://symfony.com/schema/dic/services"
xsi:schemaLocation="http://symfony.com/schema/dic/services
http://symfony.com/schema/dic/services/services-1.0.xsd">
<config>
<!-- ... -->
<firewall name="secured_area" pattern="^/admin">
<!-- ... -->
</firewall>
</config>
</srv:container>
.. code-block:: php
// app/config/security.php
// ...
$container->loadFromExtension('security', array(
'firewalls' => array(
'secured_area' => array(
'pattern' => '^/admin',
// ...
),
),
));
The ``pattern`` is a regular expression. In this example, the firewall will only be
activated if the URL starts (due to the ``^`` regex character) with ``/admin`. If
the URL does not match this pattern, the firewall will not be activated and subsequent
firewalls will have the opportunity to be matched for this request.
Restricting by Host
-------------------
.. versionadded:: 2.4
Support for restricting security firewalls to a specific host was introduced in
Symfony 2.4.
If matching against the ``pattern`` only is not enough, the request can also be matched against
``host``. When the configuration option ``host`` is set, the firewall will be restricted to
only initialize if the host from the request matches against the configuration.

.. configuration-block::

.. code-block:: yaml
# app/config/security.yml
# ...
security:
firewalls:
secured_area:
host: ^admin\.example\.com$
# ...
.. code-block:: xml
<!-- app/config/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:srv="http://symfony.com/schema/dic/services"
xsi:schemaLocation="http://symfony.com/schema/dic/services
http://symfony.com/schema/dic/services/services-1.0.xsd">
<config>
<!-- ... -->
<firewall name="secured_area" host="^admin\.example\.com$">
<!-- ... -->
</firewall>
</config>
</srv:container>
.. code-block:: php
// app/config/security.php
// ...
$container->loadFromExtension('security', array(
'firewalls' => array(
'secured_area' => array(
'host' => '^admin\.example\.com$',
// ...
),
),
));
The ``host`` (like the ``pattern``) is a regular expression. In this example,
the firewall will only be activated if the host is equal exactly (due to
the ``^`` and ``$`` regex characters) to the hostname ``admin.example.com``.
If the hostname does not match this pattern, the firewall will not be activated
and subsequent firewalls will have the opportunity to be matched for this
request.

Restricting by HTTP Methods
---------------------------

.. versionadded:: 2.5
Support for restricting security firewalls to specific HTTP methods was introduced in
Symfony 2.5.

The configuration option ``methods`` restricts the initialization of the firewall to
the provided HTTP methods.

.. configuration-block::

.. code-block:: yaml
# app/config/security.yml
# ...
security:
firewalls:
secured_area:
methods: [GET, POST]
# ...
.. code-block:: xml
<!-- app/config/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:srv="http://symfony.com/schema/dic/services"
xsi:schemaLocation="http://symfony.com/schema/dic/services
http://symfony.com/schema/dic/services/services-1.0.xsd">
<config>
<!-- ... -->
<firewall name="secured_area" methods="GET,POST">
<!-- ... -->
</firewall>
</config>
</srv:container>
.. code-block:: php
// app/config/security.php
// ...
$container->loadFromExtension('security', array(
'firewalls' => array(
'secured_area' => array(
'methods' => array('GET', 'POST'),
// ...
),
),
));
In this example, the firewall will only be activated if the HTTP method of the
request is either ``GET`` or ``POST``. If the method is not in the array of the
allowed methods, the firewall will not be activated and subsequent firewalls will again
have the opportunity to be matched for this request.
70 changes: 3 additions & 67 deletions cookbook/security/host_restriction.rst
Original file line number Diff line number Diff line change
@@ -1,70 +1,6 @@
.. index::
single: Security; Restrict Security Firewalls to a Host

How to Restrict Firewalls to a Specific Host
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a specific reason you did remove this article? I can't find something that says this is deprecated now in your PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I renamed it to firewall_restrictions
That's because I added all information on "how to restrict/match a route in the firewall" in this file and the name was not explaining is content anymore, because it has not only information about host restriction, but also http methods and pattern.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, now I see why :) You moved this more specific usecase to an article with a general overview, great choice!

However, this will break sites linking to this article. Can you please readd it, but then without text and just linking to the new article? You can see an example of this here: http://symfony.com/doc/2.3/cookbook/form/use_virtuals_forms.html

============================================

.. versionadded:: 2.4
Support for restricting security firewalls to a specific host was introduced in
Symfony 2.4.

When using the Security component, you can create firewalls that match certain
URL patterns and therefore are activated for all pages whose URL matches
that pattern. Additionally, you can restrict the initialization of a firewall
to a host using the ``host`` key:

.. configuration-block::

.. code-block:: yaml

# app/config/security.yml

# ...

security:
firewalls:
secured_area:
pattern: ^/
host: ^admin\.example\.com$
http_basic: true

.. code-block:: xml

<!-- app/config/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:srv="http://symfony.com/schema/dic/services"
xsi:schemaLocation="http://symfony.com/schema/dic/services
http://symfony.com/schema/dic/services/services-1.0.xsd">

<config>
<!-- ... -->
<firewall name="secured_area" pattern="^/" host="^admin\.example\.com$">
<http-basic />
</firewall>
</config>
</srv:container>

.. code-block:: php

// app/config/security.php

// ...

$container->loadFromExtension('security', array(
'firewalls' => array(
'secured_area' => array(
'pattern' => '^/',
'host' => '^admin\.example\.com$',
'http_basic' => true,
),
),
));

The ``host`` (like the ``pattern``) is a regular expression. In this example,
the firewall will only be activated if the host is equal exactly (due to
the ``^`` and ``$`` regex characters) to the hostname ``admin.example.com``.
If the hostname does not match this pattern, the firewall will not be activated
and subsequent firewalls will have the opportunity to be matched for this
request.
As of Symfony 2.5, more possibilities to restrict firewalls have been added.
You can read everything about all the possibilities (including ``host``)
in ":doc:`/cookbook/security/firewall_restriction`".
6 changes: 6 additions & 0 deletions reference/configuration/security.rst
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,10 @@ Each part will be explained in the next section.
Support for restricting security firewalls to a specific host was introduced in
Symfony 2.4.

.. versionadded:: 2.5
Support for restricting security firewalls to specific http methods was introduced in
Symfony 2.5.

.. configuration-block::

.. code-block:: yaml
Expand Down Expand Up @@ -104,6 +108,8 @@ Each part will be explained in the next section.
pattern: .*
# restrict the firewall to a specific host
host: admin\.example\.com
# restrict the firewall to specific http methods
methods: [GET, POST]
request_matcher: some.service.id
access_denied_url: /foo/error403
access_denied_handler: some.service.id
Expand Down