安全性

• YAML

  # app/config/security.yml
  security:
      providers:
          in_memory:
              memory: ~
  
      firewalls:
          dev:
              pattern: ^/(_(profiler|wdt)|css|images|js)/
              security: false
  
          default:
              anonymous: ~
  

• 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>
          <provider name="in_memory">
              <memory />
          </provider>
  
          <firewall name="dev"
              pattern="^/(_(profiler|wdt)|css|images|js)/"
              security=false />
  
          <firewall name="default">
              <anonymous />
          </firewall>
      </config>
  </srv:container>
  

• PHP

  // app/config/security.php
  $container->loadFromExtension('security', array(
      'providers' => array(
          'in_memory' => array(
              'memory' => array(),
          ),
      ),
      'firewalls' => array(
          'dev' => array(
              'pattern'    => '^/(_(profiler|wdt)|css|images|js)/',
              'security'   => false,
          ),
          'default' => array(
              'anonymous'  => null,
          ),
      ),
  ));
  

小技巧

You can also match a request against other details of the request (e.g. host). For more information and examples read How to Restrict Firewalls to a Specific Request.

小技巧

Security is highly configurable and there’s a Security Configuration Reference that shows all of the options with some extra explanation.

A) Configuring how your Users will Authenticate¶

The main job of a firewall is to configure how your users will authenticate. Will they use a login form? Http Basic? An API token? All of the above?

Let’s start with Http Basic (the old-school pop-up) and work up from there. To activate this, add the http_basic key under your firewall:

Simple! To try this, you need to require the user to be logged in to see a page. To make things interesting, create a new page at /admin. For example, if you use annotations, create something like this:

// src/AppBundle/Controller/DefaultController.php
// ...

use SensioBundleFrameworkExtraBundleConfigurationRoute;
use SymfonyComponentHttpFoundationResponse;

class DefaultController extends Controller
{
    /**
     * @Route("/admin")
     */
    public function adminAction()
    {
        return new Response('Admin page!');
    }
}

Next, add an access_control entry to security.yml that requires the user to be logged in to access this URL:

Great! Now, if you go to /admin, you’ll see the HTTP Basic popup:

But who can you login as? Where do users come from?

B) Configuring how Users are Loaded¶

When you type in your username, Symfony needs to load that user’s information from somewhere. This is called a “user provider”, and you’re in charge of configuring it. Symfony has a built-in way to load users from the database, or you can create your own user provider.

The easiest (but most limited) way, is to configure Symfony to load hardcoded users directly from the security.yml file itself. This is called an “in memory” provider, but it’s better to think of it as an “in configuration” provider:

Like with firewalls, you can have multiple providers, but you’ll probably only need one. If you do have multiple, you can configure which one provider to use for your firewall under its provider key (e.g. provider: in_memory).

Try to login using username admin and password kitten. You should see an error!

No encoder has been configured for account “SymfonyComponentSecurityCoreUserUser”

To fix this, add an encoders key:

User providers load user information and put it into a User object. If you load users from the database or some other source, you’ll use your own custom User class. But when you use the “in memory” provider, it gives you a SymfonyComponentSecurityCoreUserUser object.

Whatever your User class is, you need to tell Symfony what algorithm was used to encode the passwords. In this case, the passwords are just plaintext, but in a second, you’ll change this to use bcrypt.

If you refresh now, you’ll be logged in! The web debug toolbar even tells you who you are and what roles you have:

Because this URL requires ROLE_ADMIN, if you had logged in as ryan, this would deny you access. More on that later (通过URL进行权限控制（access_control）).

C) Encoding the User’s Password¶

Whether your users are stored in security.yml, in a database or somewhere else, you’ll want to encode their passwords. The best algorithm to use is bcrypt:

{
    "require": {
        ...
        "ircmaxell/password-compat": "~1.0.3"
    }
}

Of course, your user’s passwords now need to be encoded with this exact algorithm. For hardcoded users, you can use an online tool, which will give you something like this:

Everything will now work exactly like before. But if you have dynamic users (e.g. from a database), how can you programmatically encode the password before inserting them into the database? Don’t worry, see 动态加密密码 for details.

D) Configuration Done!¶

Congratulations! You now have a working authentication system that uses Http Basic and loads users right from the security.yml file.

Your next steps depend on your setup:

• Configure a different way for your users to login, like a login form or something completely custom;
• Load users from a different source, like the database or some other source;
• Learn how to deny access, load the User object and deal with roles in the Authorization section.

小技巧

In addition to roles (e.g. ROLE_ADMIN), you can protect a resource using other attributes/strings (e.g. EDIT) and use voters or Symfony’s ACL system to give these meaning. This might come in handy if you need to check if user A can “EDIT” some object B (e.g. a Product with id 5). See 权限控制列表（ACLs）: 保护单个数据.

角色¶

When a user logs in, they receive a set of roles (e.g. ROLE_ADMIN). In the example above, these are hardcoded into security.yml. If you’re loading users from the database, these are probably stored on a column in your table.

Roles are simple, and are basically strings that you invent and use as needed. For example, if you need to start limiting access to the blog admin section of your website, you could protect that section using a ROLE_BLOG_ADMIN role. This role doesn’t need to be defined anywhere - you can just start using it.

You can also specify a role hierarchy where some roles automatically mean that you also have other roles.

添加限制访问的代码¶

There are two ways to deny access to something:

1. access_control in security.yml allows you to protect URL patterns (e.g. /admin/*). This is easy, but less flexible;
2. in your code via the security.authorization_checker service.

// ...

public function helloAction($name)
{
    // The second parameter is used to specify on what object the role is tested.
    $this->denyAccessUnlessGranted('ROLE_ADMIN', null, 'Unable to access this page!');

    // Old way :
    // if (false === $this->get('security.authorization_checker')->isGranted('ROLE_ADMIN')) {
    //     throw $this->createAccessDeniedException('Unable to access this page!');
    // }

    // ...
}

// ...
use SensioBundleFrameworkExtraBundleConfigurationSecurity;

/**
 * @Security("has_role('ROLE_ADMIN')")
 */
public function helloAction($name)
{
    // ...
}

{% if app.user and is_granted('ROLE_ADMIN') %}

Checking to see if a User is Logged In (IS_AUTHENTICATED_FULLY)¶

So far, you’ve checked access based on roles - those strings that start with ROLE_ and are assigned to users. But if you only want to check if a user is logged in (you don’t care about roles), then you can see IS_AUTHENTICATED_FULLY:

// ...

public function helloAction($name)
{
    if (!$this->get('security.authorization_checker')->isGranted('IS_AUTHENTICATED_FULLY')) {
        throw $this->createAccessDeniedException();
    }

    // ...
}

IS_AUTHENTICATED_FULLY isn’t a role, but it kind of acts like one, and every user that has successfully logged in will have this. In fact, there are three special attributes like this:

• IS_AUTHENTICATED_REMEMBERED: All logged in users have this, even if they are logged in because of a “remember me cookie”. Even if you don’t use the remember me functionality, you can use this to check if the user is logged in.
• IS_AUTHENTICATED_FULLY: This is similar to IS_AUTHENTICATED_REMEMBERED, but stronger. Users who are logged in only because of a “remember me cookie” will have IS_AUTHENTICATED_REMEMBERED but will not have IS_AUTHENTICATED_FULLY.
• IS_AUTHENTICATED_ANONYMOUSLY: All users (even anonymous ones) have this - this is useful when whitelisting URLs to guarantee access - some details are in How Does the Security access_control Work?.

You can also use expressions inside your templates:

For more details on expressions and security, see Security: Complex Access Controls with Expressions.

权限控制列表（ACLs）: 保护单个数据¶

Imagine you are designing a blog where users can comment on your posts. You also want a user to be able to edit their own comments, but not those of other users. Also, as the admin user, you yourself want to be able to edit all comments.

To accomplish this you have 2 options:

• Voters allow you to use business logic (e.g. the user can edit this post because they were the creator) to determine access. You’ll probably want this option - it’s flexible enough to solve the above situation.
• ACLs allow you to create a database structure where you can assign any arbitrary user any access (e.g. EDIT, VIEW) to any object in your system. Use this if you need an admin user to be able to grant customized access across your system via some admin interface.

In both cases, you’ll still deny access using methods similar to what was shown above.

2.6 新版功能: The security.token_storage service was introduced in Symfony 2.6. Prior to Symfony 2.6, you had to use the getToken() method of the security.context service.

小技巧

The user will be an object and the class of that object will depend on your user provider.

总是检查用户登录状态¶

It’s important to check if the user is authenticated first. If they’re not, $user will either be null or the string anon.. Wait, what? Yes, this is a quirk. If you’re not logged in, the user is technically the string anon., though the getUser() controller shortcut converts this to null for convenience.

The point is this: always check to see if the user is logged in before using the User object, and use the isGranted method (or access_control) to do this:

// yay! Use this to see if the user is logged in
if (!$this->get('security.authorization_checker')->isGranted('IS_AUTHENTICATED_FULLY')) {
    throw $this->createAccessDeniedException();
}

// boo :(. Never check for the User object to see if they're logged in
if ($this->getUser()) {

}

从模板里获取用户对象¶

In a Twig Template this object can be accessed via the app.user key:

• YAML

  # app/config/security.yml
  security:
      firewalls:
          secured_area:
              # ...
              logout:
                  path:   /logout
                  target: /
      # ...
  

• 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="^/">
              <!-- ... -->
              <logout path="/logout" target="/" />
          </firewall>
          <!-- ... -->
      </config>
  </srv:container>
  

• PHP

  // app/config/security.php
  $container->loadFromExtension('security', array(
      'firewalls' => array(
          'secured_area' => array(
              // ...
              'logout' => array('path' => 'logout', 'target' => '/'),
          ),
      ),
      // ...
  ));
  

• YAML

  # app/config/routing.yml
  logout:
      path:   /logout
  

• XML

  <!-- app/config/routing.xml -->
  <?xml version="1.0" encoding="UTF-8" ?>
  <routes xmlns="http://symfony.com/schema/routing"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://symfony.com/schema/routing
          http://symfony.com/schema/routing/routing-1.0.xsd">
  
      <route id="logout" path="/logout" />
  </routes>
  

• PHP

  // app/config/routing.php
  use SymfonyComponentRoutingRouteCollection;
  use SymfonyComponentRoutingRoute;
  
  $collection = new RouteCollection();
  $collection->add('logout', new Route('/logout', array()));
  
  return $collection;
  

小技巧

If you need to do something more interesting after logging out, you can specify a logout success handler by adding a success_handler key and pointing it to a service id of a class that implements LogoutSuccessHandlerInterface. See Security Configuration Reference.

2.6 新版功能: The security.password_encoder service was introduced in Symfony 2.6.

警告

When you allow a user to submit a plaintext password (e.g. registration form, change password form), you must have validation that guarantees that the password is 4096 characters or fewer. Read more details in How to implement a simple Registration Form.

• YAML

  # app/config/security.yml
  security:
      role_hierarchy:
          ROLE_ADMIN:       ROLE_USER
          ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]
  

• 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>
          <role id="ROLE_ADMIN">ROLE_USER</role>
          <role id="ROLE_SUPER_ADMIN">ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH</role>
      </config>
  </srv:container>
  

• PHP

  // app/config/security.php
  $container->loadFromExtension('security', array(
      'role_hierarchy' => array(
          'ROLE_ADMIN'       => 'ROLE_USER',
          'ROLE_SUPER_ADMIN' => array(
              'ROLE_ADMIN',
              'ROLE_ALLOWED_TO_SWITCH',
          ),
      ),
  ));
  

• YAML

  # app/config/security.yml
  security:
      firewalls:
          main:
              http_basic: ~
              stateless:  true
  

• 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 stateless="true">
              <http-basic />
          </firewall>
      </config>
  </srv:container>
  

• PHP

  // app/config/security.php
  $container->loadFromExtension('security', array(
      'firewalls' => array(
          'main' => array('http_basic' => array(), 'stateless' => true),
      ),
  ));
  

注解

If you use a form login, Symfony will create a cookie even if you set stateless to true.

检查依赖中是否包含已知安全漏洞¶

When using lots of dependencies in your Symfony projects, some of them may contain security vulnerabilities. That’s why Symfony includes a command called security:check that checks your composer.lock file to find any known security vulnerability in your installed dependencies:

$ php app/console security:check

A good security practice is to execute this command regularly to be able to update or replace compromised dependencies as soon as possible. Internally, this command uses the public security advisories database published by the FriendsOfPHP organization.