Symfony
sponsored by SensioLabs
Menu
  • About
  • Documentation
  • Screencasts
  • Cloud
  • Certification
  • Community
  • Businesses
  • News
  • Download
  1. Home
  2. Documentation
  3. Cookbook
  4. Security
  5. How to customize your Form Login
  • Documentation
  • Book
  • Reference
  • Bundles
  • Cloud
Search by Algolia

Table of Contents

  • Form Login Configuration Reference
  • Redirecting after Success
    • Changing the Default Page
    • Always Redirect to the Default Page
    • Using the Referring URL
    • Control the Redirect URL from inside the Form
    • Redirecting on Login Failure

How to customize your Form Login

Edit this page

Warning: You are browsing the documentation for Symfony 2.2, which is no longer maintained.

Read the updated version of this page for Symfony 6.2 (the current stable version).

How to customize your Form Login

Using a form login for authentication is a common, and flexible, method for handling authentication in Symfony2. Pretty much every aspect of the form login can be customized. The full, default configuration is shown in the next section.

Form Login Configuration Reference

To see the full form login configuration reference, see SecurityBundle Configuration ("security"). Some of the more interesting options are explained below.

Redirecting after Success

You can change where the login form redirects after a successful login using the various config options. By default the form will redirect to the URL the user requested (i.e. the URL which triggered the login form being shown). For example, if the user requested http://www.example.com/admin/post/18/edit, then after they successfully log in, they will eventually be sent back to http://www.example.com/admin/post/18/edit. This is done by storing the requested URL in the session. If no URL is present in the session (perhaps the user went directly to the login page), then the user is redirected to the default page, which is / (i.e. the homepage) by default. You can change this behavior in several ways.

Note

As mentioned, by default the user is redirected back to the page originally requested. Sometimes, this can cause problems, like if a background Ajax request "appears" to be the last visited URL, causing the user to be redirected there. For information on controlling this behavior, see How to change the Default Target Path Behavior.

Changing the Default Page

First, the default page can be set (i.e. the page the user is redirected to if no previous page was stored in the session). To set it to the default_security_target route use the following config:

  • YAML
  • XML
  • PHP
1
2
3
4
5
6
7
# app/config/security.yml
security:
    firewalls:
        main:
            form_login:
                # ...
                default_target_path: default_security_target
1
2
3
4
5
6
7
8
<!-- app/config/security.xml -->
<config>
    <firewall>
        <form-login
            default_target_path="default_security_target"
        />
    </firewall>
</config>
1
2
3
4
5
6
7
8
9
10
11
12
13
// app/config/security.php
$container->loadFromExtension('security', array(
    'firewalls' => array(
        'main' => array(
            // ...

            'form_login' => array(
                // ...
                'default_target_path' => 'default_security_target',
            ),
        ),
    ),
));

Now, when no URL is set in the session, users will be sent to the default_security_target route.

Always Redirect to the Default Page

You can make it so that users are always redirected to the default page regardless of what URL they had requested previously by setting the always_use_default_target_path option to true:

  • YAML
  • XML
  • PHP
1
2
3
4
5
6
7
# app/config/security.yml
security:
    firewalls:
        main:
            form_login:
                # ...
                always_use_default_target_path: true
1
2
3
4
5
6
7
8
<!-- app/config/security.xml -->
<config>
    <firewall>
        <form-login
            always_use_default_target_path="true"
        />
    </firewall>
</config>
1
2
3
4
5
6
7
8
9
10
11
12
13
// app/config/security.php
$container->loadFromExtension('security', array(
    'firewalls' => array(
        'main' => array(
            // ...

            'form_login' => array(
                // ...
                'always_use_default_target_path' => true,
            ),
        ),
    ),
));

Using the Referring URL

In case no previous URL was stored in the session, you may wish to try using the HTTP_REFERER instead, as this will often be the same. You can do this by setting use_referer to true (it defaults to false):

  • YAML
  • XML
  • PHP
1
2
3
4
5
6
7
# app/config/security.yml
security:
    firewalls:
        main:
            form_login:
                # ...
                use_referer:        true
1
2
3
4
5
6
7
8
<!-- app/config/security.xml -->
<config>
    <firewall>
        <form-login
            use_referer="true"
        />
    </firewall>
</config>
1
2
3
4
5
6
7
8
9
10
11
12
13
// app/config/security.php
$container->loadFromExtension('security', array(
    'firewalls' => array(
        'main' => array(
            // ...

            'form_login' => array(
                // ...
                'use_referer' => true,
            ),
        ),
    ),
));

2.1

As of 2.1, if the referer is equal to the login_path option, the user will be redirected to the default_target_path.

Control the Redirect URL from inside the Form

You can also override where the user is redirected to via the form itself by including a hidden field with the name _target_path. For example, to redirect to the URL defined by some account route, use the following:

  • Twig
  • PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{# src/Acme/SecurityBundle/Resources/views/Security/login.html.twig #}
{% if error %}
    <div>{{ error.message }}</div>
{% endif %}

<form action="{{ path('login_check') }}" method="post">
    <label for="username">Username:</label>
    <input type="text" id="username" name="_username" value="{{ last_username }}" />

    <label for="password">Password:</label>
    <input type="password" id="password" name="_password" />

    <input type="hidden" name="_target_path" value="account" />

    <input type="submit" name="login" />
</form>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<!-- src/Acme/SecurityBundle/Resources/views/Security/login.html.php -->
<?php if ($error): ?>
    <div><?php echo $error->getMessage() ?></div>
<?php endif; ?>

<form action="<?php echo $view['router']->generate('login_check') ?>" method="post">
    <label for="username">Username:</label>
    <input type="text" id="username" name="_username" value="<?php echo $last_username ?>" />

    <label for="password">Password:</label>
    <input type="password" id="password" name="_password" />

    <input type="hidden" name="_target_path" value="account" />

    <input type="submit" name="login" />
</form>

Now, the user will be redirected to the value of the hidden form field. The value attribute can be a relative path, absolute URL, or a route name. You can even change the name of the hidden form field by changing the target_path_parameter option to another value.

  • YAML
  • XML
  • PHP
1
2
3
4
5
6
# app/config/security.yml
security:
    firewalls:
        main:
            form_login:
                target_path_parameter: redirect_url
1
2
3
4
5
6
7
8
<!-- app/config/security.xml -->
<config>
    <firewall>
        <form-login
            target_path_parameter="redirect_url"
        />
    </firewall>
</config>
1
2
3
4
5
6
7
8
9
10
// app/config/security.php
$container->loadFromExtension('security', array(
    'firewalls' => array(
        'main' => array(
            'form_login' => array(
                'target_path_parameter' => redirect_url,
            ),
        ),
    ),
));

Redirecting on Login Failure

In addition to redirecting the user after a successful login, you can also set the URL that the user should be redirected to after a failed login (e.g. an invalid username or password was submitted). By default, the user is redirected back to the login form itself. You can set this to a different route (e.g. login_failure) with the following config:

  • YAML
  • XML
  • PHP
1
2
3
4
5
6
7
# app/config/security.yml
security:
    firewalls:
        main:
            form_login:
                # ...
                failure_path: login_failure
1
2
3
4
5
6
7
8
<!-- app/config/security.xml -->
<config>
    <firewall>
        <form-login
            failure_path="login_failure"
        />
    </firewall>
</config>
1
2
3
4
5
6
7
8
9
10
11
12
13
// app/config/security.php
$container->loadFromExtension('security', array(
    'firewalls' => array(
        'main' => array(
            // ...

            'form_login' => array(
                // ...
                'failure_path' => 'login_failure',
            ),
        ),
    ),
));
This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
We stand with Ukraine.
Version:
Code consumes server resources. Blackfire tells you how

Code consumes server resources. Blackfire tells you how

Peruse our complete Symfony & PHP solutions catalog for your web development needs.

Peruse our complete Symfony & PHP solutions catalog for your web development needs.

↓ Our footer now uses the colors of the Ukrainian flag because Symfony stands with the people of Ukraine.

Avatar of Anthony MARTIN, a Symfony contributor

Thanks Anthony MARTIN for being a Symfony contributor

13 commits • 1.00K lines changed

View all contributors that help us make Symfony

Become a Symfony contributor

Be an active part of the community and contribute ideas, code and bug fixes. Both experts and newcomers are welcome.

Learn how to contribute

Symfony™ is a trademark of Symfony SAS. All rights reserved.

  • What is Symfony?
    • Symfony at a Glance
    • Symfony Components
    • Case Studies
    • Symfony Releases
    • Security Policy
    • Logo & Screenshots
    • Trademark & Licenses
    • symfony1 Legacy
  • Learn Symfony
    • Symfony Docs
    • Symfony Book
    • Reference
    • Bundles
    • Best Practices
    • Training
    • eLearning Platform
    • Certification
  • Screencasts
    • Learn Symfony
    • Learn PHP
    • Learn JavaScript
    • Learn Drupal
    • Learn RESTful APIs
  • Community
    • SymfonyConnect
    • Support
    • How to be Involved
    • Code of Conduct
    • Events & Meetups
    • Projects using Symfony
    • Downloads Stats
    • Contributors
    • Backers
  • Blog
    • Events & Meetups
    • A week of symfony
    • Case studies
    • Cloud
    • Community
    • Conferences
    • Diversity
    • Documentation
    • Living on the edge
    • Releases
    • Security Advisories
    • SymfonyInsight
    • Twig
    • SensioLabs
  • Services
    • SensioLabs services
    • Train developers
    • Manage your project quality
    • Improve your project performance
    • Host Symfony projects
    Deployed on
Follow Symfony
Search by Algolia