Merge remote-tracking branch 'upstream/7.3' into 7.3

* upstream/7.3:
  Fix more heading levels in the security reference
  Update overview.rst
  update internal ref in event dispatcher

contributing/documentation/overview.rst

@@ -113,16 +113,16 @@ memorable name for the new branch (if you are fixing a reported issue, use
 
 .. code-block:: terminal
 
-    $ git checkout -b improve_install_article upstream/5.4
+    $ git checkout -b improve_install_article upstream/6.4
 
 In this example, the name of the branch is ``improve_install_article`` and the
-``upstream/5.4`` value tells Git to create this branch based on the ``5.4``
+``upstream/6.4`` value tells Git to create this branch based on the ``6.4``
 branch of the ``upstream`` remote, which is the original Symfony Docs repository.
 
 Fixes should always be based on the **oldest maintained branch** which contains
-the error. Nowadays this is the ``5.4`` branch. If you are instead documenting a
+the error. Nowadays this is the ``6.4`` branch. If you are instead documenting a
 new feature, switch to the first Symfony version that included it, e.g.
-``upstream/6.2``.
+``upstream/7.2``.
 
 **Step 5.** Now make your changes in the documentation. Add, tweak, reword and
 even remove any content and do your best to comply with the
@@ -156,7 +156,7 @@ changes should be applied:
     :alt: The base branch select option on the GitHub page.
 
 In this example, the **base fork** should be ``symfony/symfony-docs`` and
-the **base** branch should be the ``5.4``, which is the branch that you selected
+the **base** branch should be the ``4.4``, which is the branch that you selected
 to base your changes on. The **head fork** should be your forked copy
 of ``symfony-docs`` and the **compare** branch should be ``improve_install_article``,
 which is the name of the branch you created and where you made your changes.
@@ -209,7 +209,7 @@ contribution to the Symfony docs:
     # create a new branch based on the oldest maintained version
     $ cd projects/symfony-docs/
     $ git fetch upstream
-    $ git checkout -b my_changes upstream/5.4
+    $ git checkout -b my_changes upstream/6.4
 
     # ... do your changes
 
@@ -258,8 +258,8 @@ into multiple branches, corresponding to the different versions of Symfony itsel
 The latest (e.g. ``5.x``) branch holds the documentation for the development branch of
 the code.
 
-Unless you're documenting a feature that was introduced after Symfony 5.4,
-your changes should always be based on the ``5.4`` branch. Documentation managers
+Unless you're documenting a feature that was introduced after Symfony 6.4,
+your changes should always be based on the ``6.4`` branch. Documentation managers
 will use the necessary Git-magic to also apply your changes to all the active
 branches of the documentation.
 

event_dispatcher.rst

@@ -541,7 +541,7 @@ Creating an Event Subscriber
 
 Next, you'll need to create an event subscriber, which will hold the logic
 that you want to be executed before your controllers. If you're not familiar with
-event subscribers, you can learn more about them at :doc:`/event_dispatcher`::
+event subscribers, you can learn more about :ref:`how to use them <events-subscriber>`::
 
     // src/EventSubscriber/TokenSubscriber.php
     namespace App\EventSubscriber;

reference/configuration/security.rst

@@ -38,86 +38,15 @@ separate articles:
 * `role_hierarchy`_
 
 access_denied_url
-~~~~~~~~~~~~~~~~~
+-----------------
 
 **type**: ``string`` **default**: ``null``
 
 Defines the URL where the user is redirected after a ``403`` HTTP error (unless
 you define a custom access denial handler). Example: ``/no-permission``
 
-delete_cookies
-~~~~~~~~~~~~~~
-
-**type**: ``array`` **default**: ``[]``
-
-Lists the names (and other optional features) of the cookies to delete when the
-user logs out::
-
-.. configuration-block::
-
-    .. code-block:: yaml
-
-        # config/packages/security.yaml
-        security:
-            # ...
-
-            firewalls:
-                main:
-                    # ...
-                    logout:
-                        delete_cookies:
-                            cookie1-name: null
-                            cookie2-name:
-                                path: '/'
-                            cookie3-name:
-                                path: null
-                                domain: example.com
-
-    .. code-block:: xml
-
-        <!-- config/packages/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
-                https://symfony.com/schema/dic/services/services-1.0.xsd">
-
-            <config>
-                <!-- ... -->
-
-                <firewall name="main">
-                    <!-- ... -->
-                    <logout path="...">
-                        <delete-cookie name="cookie1-name"/>
-                        <delete-cookie name="cookie2-name" path="/"/>
-                        <delete-cookie name="cookie3-name" domain="example.com"/>
-                    </logout>
-                </firewall>
-            </config>
-        </srv:container>
-
-    .. code-block:: php
-
-        // config/packages/security.php
-
-        // ...
-
-        return static function (SecurityConfig $securityConfig): void {
-            // ...
-
-            $securityConfig->firewall('main')
-                ->logout()
-                    ->deleteCookie('cookie1-name')
-                    ->deleteCookie('cookie2-name')
-                        ->path('/')
-                    ->deleteCookie('cookie3-name')
-                        ->path(null)
-                        ->domain('example.com');
-        };
-
 erase_credentials
-~~~~~~~~~~~~~~~~~
+-----------------
 
 **type**: ``boolean`` **default**: ``true``
 
@@ -125,7 +54,7 @@ If ``true``, the ``eraseCredentials()`` method of the user object is called
 after authentication.
 
 hide_user_not_found
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 **type**: ``boolean`` **default**: ``true``
 
@@ -138,7 +67,7 @@ If ``false``, the exception thrown is of type
 and it includes the given not found user identifier.
 
 session_fixation_strategy
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 **type**: ``string`` **default**: ``SessionAuthenticationStrategy::MIGRATE``
 
@@ -157,7 +86,7 @@ The possible values of this option are:
   other session attributes are lost.
 
 access_control
-~~~~~~~~~~~~~~
+--------------
 
 Defines the security protection of the URLs of your application. It's used for
 example to trigger the user authentication when trying to access to the backend
@@ -166,7 +95,7 @@ and to allow unauthenticated users to the login form page.
 This option is explained in detail in :doc:`/security/access_control`.
 
 firewalls
-~~~~~~~~~
+---------
 
 This is arguably the most important option of the security config file. It
 defines the authentication mechanism used for each URL (or URL pattern) of your
@@ -427,7 +356,7 @@ delete_cookies
 **type**: ``array`` **default**: ``[]``
 
 Lists the names (and other optional features) of the cookies to delete when the
-user logs out::
+user logs out:
 
 .. configuration-block::