order of the arguments, Symfony will still pass the correct value to each

variable.

.._checking-the-validity-of-a-csrf-token::

Validating a CSRF Token

In addition to the URL, you can also match on the *method* of the incoming

request (i.e. GET, HEAD, POST, PUT, DELETE). Suppose youhave a contact form

with two controllers - onefor displayingthe form (on a GETrequest) and one

for processing the form when it's submitted (on aPOST request). This can

beaccomplished with the following route configuration:

request (i.e. GET, HEAD, POST, PUT, DELETE). Suppose youcreate an API for

your blog and you have 2 routes: Onefor displayinga post (on a GETor HEAD

request) and one for updating a post (on aPUT request). This can be

accomplished with the following route configuration:

..configuration-block::

..code-block::yaml

..code-block::xml

Despite the fact that these two routes have identical paths (``/contact``),

the first route will match only GET requests and the second route will match

only POST requests. This means that you can display the form and submit the

form via the same URL, while using distinct controllers for the two actions.

Despite the fact that these two routes have identical paths

(``/api/posts/{id}``), the first route will match only GET or HEAD requests and

the second route will match only PUT requests. This means that you can display

and edit the post with the same URL, while using distinct controllers for the

two actions.

..note::

of custom variables can be *anything* that's significant to your application,

and is returned when that route is matched.

If no matching route can be found a

:class:`Symfony\\Component\\Routing\\Exception\\ResourceNotFoundException` will be thrown.

The:method:`UrlMatcher::match() <Symfony\\Component\\Routing\\UrlMatcher::match>`

returns the variables you set on the route as well as the wildcard placeholders

(see below). Your application can now use this information to continue

processing the request. In addition to the configured variables, a ``_route``

key is added, which holds the name of the matched route.

In addition to your array of custom variables, a ``_route`` key is added,

which holds the name of the matched route.

If no matching route can be found, a

:class:`Symfony\\Component\\Routing\\Exception\\ResourceNotFoundException` will

be thrown.

Defining Routes

wildcard matches the regular expression wildcard given. However, ``/archive/foo``

does *not* match, because "foo" fails the month wildcard.

When using wildcards, these are returned in the array result when calling

``match``. The part of the path that the wildcard matched (e.g. ``2012-01``) is used

as value.

..tip::

If you want to match all URLs which start with a certain path and end in an

Authentication Events

The security component provides 4 related authentication events:

Name Event Constant Argument Passed to the Listener

security.authentication.success ``AuthenticationEvents::AUTHENTICATION_SUCCESS``:class:`Symfony\Component\Security\Core\Event\AuthenticationEvent`

security.authentication.failure ``AuthenticationEvents::AUTHENTICATION_FAILURE``:class:`Symfony\Component\Security\Core\Event\AuthenticationFailureEvent`

security.interactive_login ``SecurityEvents::INTERACTIVE_LOGIN``:class:`Symfony\Component\Security\Http\Event\InteractiveLoginEvent`

security.switch_user ``SecurityEvents::SWITCH_USER``:class:`Symfony\Component\Security\Http\Event\SwitchUserEvent`

Authentication Success and Failure Events

When a provider authenticates the user, a ``security.authentication.success``

event is dispatched. But beware - this event will fire, for example, on *every*

request if you have session-based authentication. See ``security.interactive_login``

below if you need to do something when a user *actually* logs in.

When a provider attempts authentication but fails (i.e. throws an ``AuthenticationException``),

a ``security.authentication.failure`` event is dispatched. You could listen on

the ``security.authentication.failure`` event, for example, in order to log

failed login attempts.

Security Events

The ``security.interactive_login`` event is triggered after a user has actively

logged into your website. It is important to distinguish this action from

non-interactive authentication methods, such as:

* authentication based on a "remember me" cookie.

* authentication based on your session.

* authentication using a HTTP basic or HTTP digest header.

You could listen on the ``security.interactive_login`` event, for example, in

order to give your user a welcome flash message every time they log in.

The ``security.switch_user`` event is triggered every time you activate

the ``switch_user`` firewall listener.

..seealso::

For more information on switching users, see

:doc:`/cookbook/security/impersonating_user`.

.. _`CVE-2013-5750`:https://symfony.com/blog/cve-2013-5750-security-issue-in-fosuserbundle-login-form

.. _`BasePasswordEncoder::checkPasswordLength`:https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/Encoder/BasePasswordEncoder.php