symofony给我们提供了一个refresh方法：

$em = $this->getDoctrine()->getManager();
        $XXXX =  $request->files->get('XXXX');
        $Uploadfileentity = new UploadfileEntity();
        $Uploadfileentity->setImagefile($XXXX);
        $em->persist($Uploadfileentity);
        $em->flush();
        // 及时从数据库更新持久化
        $em->refresh($Uploadfileentity);

        $returnarar = array('success' => 1,'message' => '上传成功!','url' => $Uploadfileentity->getImagepath());

        return new JsonResponse($returnarar);

这段代码的意思是，你获取一个上传的文件，然后将文件赋值给entity处理，entity负责上传入库。

如果没有填写$em->refresh($Uploadfileentity);  恐怕你永远也不能及时获取到 $Uploadfileentity->getImagepath()的路径值。

flush完entity后及时更新entity，首发于Symfony中文教程。

盐（Salt）

在密码学中，是指通过在密码任意固定位置插入特定的字符串，让散列后的结果和使用原始密码的散列结果不相符，这种过程称之为“加盐”。

以上这句话是维基百科上对于 Salt 的定义，但是仅凭这句话还是很难理解什么叫 Salt，以及它究竟起到什么作用。

第一代密码

早期的软件系统或者互联网应用，数据库中设计用户表的时候，大致是这样的结构：

mysql> desc User;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| UserName | varchar(50)  | NO   |     |         |       |
| PassWord | varchar(150) | NO   |     |         |       |
+----------+--------------+------+-----+---------+-------+

数据存储形式如下：

mysql> select * from User;
+----------+----------+
| UserName | PassWord |
+----------+----------+
| lichao   | 123      |
| akasuna  | 456      |
+----------+----------+

主要的关键字段就是这么两个，一个是登陆时的用户名，对应的一个密码，而且那个时候的用户名是明文存储的，如果你登陆时用户名是 123，那么数据库里存的就是 123。这种设计思路非常简单，但是缺陷也非常明显，数据库一旦泄露，那么所有用户名和密码都会泄露，后果非常严重。参见《CSDN 详解 600 万用户密码泄露始末》。

第二代密码

为了规避第一代密码设计的缺陷，聪明的人在数据库中不在存储明文密码，转而存储加密后的密码，典型的加密算法是 MD5 和 SHA1，其数据表大致是这样设计的：

mysql> desc User;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| UserName | varchar(50)  | NO   |     |         |       |
| PwdHash  | char(32)     | NO   |     |         |       |
+----------+--------------+------+-----+---------+-------+

数据存储形式如下：

mysql> select * from User;
+----------+----------------------------------+
| UserName | PwdHash                          |
+----------+----------------------------------+
| lichao   | 202cb962ac59075b964b07152d234b70 |
| akasuna  | 250cf8b51c773f3f8dc8b4be867a9a02 |
+----------+----------------------------------+

假如你设置的密码是 123，那么数据库中存储的就是 202cb962ac59075b964b07152d234b70 或 40bd001563085fc35165329ea1ff5c5ecbdbbeef。当用户登陆的时候，会把用户输入的密码执行 MD5（或者 SHA1）后再和数据库就行对比，判断用户身份是否合法，这种加密算法称为散列。

严格地说，这种算法不能算是加密，因为理论上来说，它不能被解密。所以即使数据库丢失了，但是由于数据库里的密码都是密文，根本无法判断用户的原始密码，所以后果也不算太严重。

第三代密码

本来第二代密码设计方法已经很不错了，只要你密码设置得稍微复杂一点，就几乎没有被破解的可能性。但是如果你的密码设置得不够复杂，被破解出来的可能性还是比较大的。

好事者收集常用的密码，然后对他们执行 MD5 或者 SHA1，然后做成一个数据量非常庞大的数据字典，然后对泄露的数据库中的密码就行对比，如果你的原始密码很不幸的被包含在这个数据字典中，那么花不了多长时间就能把你的原始密码匹配出来。这个数据字典很容易收集，CSDN 泄露的那 600w 个密码，就是很好的原始素材。

于是，第三代密码设计方法诞生，用户表中多了一个字段：

mysql> desc User;
+----------+-------------+------+-----+---------+-------+
| Field    | Type        | Null | Key | Default | Extra |
+----------+-------------+------+-----+---------+-------+
| UserName | varchar(50) | NO   |     |         |       |
| Salt     | char(50)    | NO   |     |         |       |
| PwdHash  | char(32)    | NO   |     |         |       |
+----------+-------------+------+-----+---------+-------+

数据存储形式如下：

mysql> select * from User;
+----------+----------------------------+----------------------------------+
| UserName | Salt                       | PwdHash                          |
+----------+----------------------------+----------------------------------+
| lichao   | 1ck12b13k1jmjxrg1h0129h2lj | 6c22ef52be70e11b6f3bcf0f672c96ce |
| akasuna  | 1h029kh2lj11jmjxrg13k1c12b | 7128f587d88d6686974d6ef57c193628 |
+----------+----------------------------+----------------------------------+

Salt 可以是任意字母、数字、或是字母或数字的组合，但必须是随机产生的，每个用户的 Salt 都不一样，用户注册的时候，数据库中存入的不是明文密码，也不是简单的对明文密码进行散列，而是 MD5( 明文密码 + Salt)，也就是说：

MD5('123' + '1ck12b13k1jmjxrg1h0129h2lj') = '6c22ef52be70e11b6f3bcf0f672c96ce'
MD5('456' + '1h029kh2lj11jmjxrg13k1c12b') = '7128f587d88d6686974d6ef57c193628'

当用户登陆的时候，同样用这种算法就行验证。

由于加了 Salt，即便数据库泄露了，但是由于密码都是加了 Salt 之后的散列，坏人们的数据字典已经无法直接匹配，明文密码被破解出来的概率也大大降低。

是不是加了 Salt 之后就绝对安全了呢？淡然没有！坏人们还是可以他们数据字典中的密码，加上我们泄露数据库中的 Salt，然后散列，然后再匹配。但是由于我们的 Salt 是随机产生的，假如我们的用户数据表中有 30w 条数据，数据字典中有 600w 条数据，坏人们如果想要完全覆盖的坏，他们加上 Salt 后再散列的数据字典数据量就应该是 300000* 6000000 = 1800000000000，一万八千亿啊，干坏事的成本太高了吧。但是如果只是想破解某个用户的密码的话，只需为这 600w 条数据加上 Salt，然后散列匹配。可见 Salt 虽然大大提高了安全系数，但也并非绝对安全。

实际项目中，Salt 不一定要加在最前面或最后面，也可以插在中间嘛，也可以分开插入，也可以倒序，程序设计时可以灵活调整，都可以使破解的难度指数级增长。

注，文中所谓第一、二、三代密码的称呼，是我自己 YY 的。

密码学中的“盐值 Salt”，首发于Symfony中文教程。

[{},{},{}....]

什么情况？呢

其实是我们的entity类的属性为私有化的问题。解决起来也很简单，就是修改我们相关的entity类：

namespace AppBundle\Entity;
....
class XXXXXXX implements JsonSerializable
{
  private $id;
  private $title;
  private $content;

  ....

  public function jsonSerialize()
    {
        return array(
            'id'=> $this->id,
            'title' => $this->title,
            'content' => $this->content,
        );
    }
}

核心就是实现JsonSerializable的jsonSerialize()方法，返回需要的属性为一个数组。

我们在controller中测试一下：

public function indexAction(Request $request)
    {
        $em=$this->getDoctrine()->getManager();
        $entities=$em->getRepository('AppBundle:XXXXXXXXX')->findAll();

        $response = new JsonResponse();
        $response->headers->set('Content-Type', 'application/json');
        $response->headers->set('Access-Control-Allow-Origin', '*');

        $response->setEncodingOptions(JSON_UNESCAPED_UNICODE);
        $response->setData($entities);

        return $response;
    }

其中有一行

$response->setEncodingOptions(JSON_UNESCAPED_UNICODE);

此句话是用来处理JSON 编码，如果没有此句，你输出的Json数据很可能出现如下状况：

{\u0022id\u0022:1,\u0022iam\u0022:1

setEncodingOptions相关参数请查看：http://php.net/manual/zh/json.constants.php

symfony中JsonResponse处理findAll数据集和编码，首发于Symfony中文教程。

{# endDate 和 startDate 是 string or DateTime 对象 #}
{% set difference = date(endDate).diff(date(startDate)) %}
{% set leftDays = difference.days %}

  {{ leftDays }} days

Twig中计算两个时间之间的天数，首发于Symfony中文教程。

获取当前时间

$date = new DateTime('2000-01-01');
// OR
$date = new DateTime('now');

增加10天

用 DateInterval 与 DateTime::add()

$date   = new DateTime('2000-01-01');
$day    = new DateInterval('P10D'); // P开头代表日期，10D 代表 10 天
$date->add($day); 
echo $date->format('Y-m-d') ;

用 DateTime::modify()

$date = new DateTime('2006-12-12');
$date->modify('+10 day');
echo $date->format('Y-m-d');

减少一个月

$date = new DateTime('2000-12-31');

$date->modify('-1 month');
echo $date->format('Y-m-d') ;

用 DateInterval 增加两年四天六小时又八分

$date   = new DateTime('2000-01-01');
$day    = new DateInterval('P2Y4DT6H8M'); // 两年四天六小時又八分，中间的 T 是时间的意思
$date->add($day); 
echo $date->format('Y-m-d') ;

DateInterval 的写法说明

new DateInterval('P1Y2M3D'); // P开头表示日期，一年二個月又三天

new DateInterval('PT4H5M6S'); // T开头表示時間，四小時五分又六秒

new DateInterval('P1Y2M3DT4H5M6S'); // 合并起來，一年二个月三天四小時五分又六秒

new DateInterval('P3M'); // 三个月

new DateInterval('PT1H'); // 一小时

两个时间相减计算出天数

$datetime1 = new DateTime('2013-12-23 16:13:08');
$datetime2 = new DateTime('2012-11-22 12:05:07');
$interval = $datetime1->diff($datetime2);
echo $interval->format('%d天%H小时%i分%s秒');  //输出时间字符串
echo $interval->days;   //输出两个日期相差天数

$datetime1->diff()方法会返回DateInterval对象，具体细节可查看 php DateInterval 手册。

注意：

$date=new \DateTime();
$time1=$date;
$day=new DateInterval('P5D');
$time2=$date->add($day);

你会发现，输出的$time1 和 $time2是一样的。这很好处理，我们只需要加上clone 即可

$date=new \DateTime();
$time1=clone $date;
$day=new DateInterval('P5D');
$time2=$date->add($day);

这时$time1和$time2就不同步了

PHP Datetime 时间的增减方式，首发于Symfony中文教程。

或者有些会员违反了，网站的规定，网站及时将其降权，防止此会员的恶意行为。这都需要角色变换后的及时更新，也就是对用户的重新加载。

在User Entity下手

很简单，只需要用到EquatableInterface接口，在这个接口中有一个函数isEqualTo，我们实现了它就可以了：

class User extends BaseUser implements EquatableInterface
{
    ........
    public function isEqualTo(UserInterface $user)
    {
        // TODO: Implement isEqualTo() method.
        return
            md5($user->getUsername()) == md5($this->getUsername()) &&
            md5(serialize($user->getRoles())) == md5(serialize($this->getRoles()));
    }
.......

这个方法返回ture等于用户没有变动，如果返回false就会重新加载用户。

如何使用

来到indexAction，确保你的程序已经登录。并且登录用户不存在“ROLE_ADVANT”角色

public function indexAction(Request $request)
    {
        $em=$this->getDoctrine()->getManager();
        $userentity=$this->getUser();
       // $userentity->setRoles(array('ROLE_ADVANT','ROLE_ADMIN'));
        $userentity->addRole('ROLE_ADVANT');

        $em->persist($userentity);
        $em->flush();

        return $this->render('default/index.html.twig', array(
        ));

    }

twig模板要加入判断以便演示（当然也可以查看debug工具中的security）：

{% if is_granted('ROLE_ADVANT') %}
   已成功添加 ROLE_ADVANT
{% endif %}

ok，你已经成功的重新加载了用户。

注意：在indexAction中不要加入$this->isGranted(“ROLE_XXX”)，来做判断，否则重新加载不会启用。

当然，还有别的方法。例如，重新生成Token

$em = $this->getDoctrine()->getManager();
$loggedInUser = $this->get('security.context')->getToken()->getUser();
$loggedInUser->addRole('ROLE_XYZ');

$em->persist($loggedInUser);
$em->flush();

$token = new \Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken(
  $loggedInUser,
  null,
  'main',
  $loggedInUser->getRoles()
);

$this->container->get('security.context')->setToken($token);

这个文章可供参考：

How to reload your User after changes in Symfony2

FOSUserBundle重新加载用户，首发于Symfony中文教程。

这是一篇受密码保护的文章，您需要提供访问密码：

密码：

密码保护：创建简单的vendor目录bunle并在项目中使用它，首发于Symfony中文教程。

举一个简单例子：

在控制器中我们如何创建一个flash message:

$this->addFlash(
            'notice',
            '你想要放置的消息'
        );
 
        // $this->addFlash 就相当于 $this->get('session')->getFlashBag()->add
 
        return $this->redirectToRoute(...); //跳转页面了

上面这段代码，就很容易的创建了消息，并跳转到其他页面。其他页面可以在twig模板中直接接收此信息并展示，代码如下：

{% for flash_message in app.session.flashBag.get('notice') %}
    <div class="flash-notice">
        {{ flash_message }}
    </div>
{% endfor %}

来看看这里app.session.flashBag.get(‘notice’)，并用dump在twig模板中输出一下

{{ dump(app.session.flashBag.get('notice')) }}

会得到一个数组

array:1 [▼
  0 => "你想要放置的消息"
]

所以我们要使用for去遍历它们，使其获得相应的消息并输出。

Symfony消息提醒Flash Message，首发于Symfony中文教程。

{# defined works with variable names #}
{% if foo is defined %}
    ...
{% endif %}

{# and attributes on variables names #}
{% if foo.bar is defined %}
    ...
{% endif %}

{% if foo['bar'] is defined %}
    ...
{% endif %}

具体可参见：Twig defined。

当然，如果你想检查一个已存在变量是否为空，也是很容易的：

{% if var is null %}
    {# do something #}
{% endif %}

当然还有一种比较严格的比对方式：

{% if var is sameas(false) %}
    {# do something %}
{% endif %}

具体可参见：Twig sameas。

如果这个变量为：array(0) { }一个空数组，那么下面的判断很有效

{% if var|length > 0 %}
    {# do something #}
{% endif %}

（非twig）action中的EntityRepository->find()方法会返回一个object对象，如果数据库中没有回返回null。以下方式展示如何判断：

public function showAction($productId)
{
    $product = $this->getDoctrine()
        ->getRepository('AppBundle:Product')
        ->find($productId);

    if (!$product) {
        throw $this->createNotFoundException(
            'No product found for id '.$productId
        );
    }

    // ... do something, like pass the $product object into a template
}

或者

if (null !== $entity) {
}

if ($entity instanceof Representative) {
}

Twig中判断变量是否存在，首发于Symfony中文教程。

现在symfony已经更新到了3.0，一个新的组件也被包含到了symfony框架体系：Guard。这个组件的目的是与安全系统集成,并提供一个更简单的方法。他公开了一个单个接口，把你从身份验证开始到结束都链起来：逻辑和所有组合都在一起。

在这篇文章里，我们来创建一个简单的表单验证，需要一个用户登录并给他ROLE_ADMIN角色到每一个页面。原始的方式是创建一个form authentication，他现在仍然可以使用，但我们将使用这样一个简单的步骤来举例说明Guard。你就能够了解这个概念并复用到其他的验证（token,社交媒体等）。

安全配置

这个安全配置将需要一个用户类（来表示用户数据）还需要UserProvider（获取用户数据）。为了让事情简单，我们直接使用InMemory用户提供器（user provider）自然而然的我们使用默认的symfony的User类。我们的security.yml就是这个样子：

security:
    providers:
        in_memory:
            memory:
                users:
                    admin:
                        password: admin
                        roles: 'ROLE_ADMIN'

更多关于symfony安全系统的文章请阅读book。

我们的InMemory提供器现在有一个写死的test用户并付给他ROLE_ADMIN.

下面是我们定义的防火墙：

secured_area
            anonymous: ~
            logout:
                path:   /logout
                target: /
            guard:
                authenticators:
                    - form_authenticator

上面基本上是说，匿名用户可以访问防火墙路径，还记录了用户退出路径。这个新的guard键是表明防火墙使用Guard配置的验证器：form_authenticator。他传入的是服务名称并且我们将在下一分钟内看到他的定义。

最后在安全配置中,我们可以指定一些访问规则:

access_control:
            - { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
            - { path: ^/, roles: ROLE_ADMIN }

在这个示例中,我们指定没有登录的用户只能访问/login路径。对于其他用户要有ROLE_ADMIN角色。

登录控制器（Login Controller）

在真正做身份验证之前，让我们看看实际的登录表单和控制器。DefaultController的action里面：

/**
   * @Route("/login", name="login")
   */
  public function loginAction(Request $request)
  {
    $user = $this->getUser();
    if ($user instanceof UserInterface) {
      return $this->redirectToRoute('homepage');
    }

    /** @var AuthenticationException $exception */
    $exception = $this->get('security.authentication_utils')
      ->getLastAuthenticationError();

    return $this->render('default/login.html.twig', [
      'error' => $exception ? $exception->getMessage() : NULL,
    ]);
  }

定义了/login路由，这个action只是负责显示一个基本的登录表单，用户不登录。twig模板如下：

{{ error }}

<form action="{{ path('login') }}" method="POST">
    <label for="username">Username</label>
    <input type="text" name="username" class="form-control" id="username" placeholder="Username">
    <label for="password">Password</label>
    <input type="password" name="password" class="form-control"
           id="password" placeholder="Password">
    <button type="submit">Login</button>
</form>

到目前为止，没啥特别的。只是一个简单的表单html。

Guard Authenticator 服务

我们在安全配置文件中引用了我们的Guard authenticator服务。让我们确保在sservices.yml中有这个服务定义：

services:
    form_authenticator:
          class: AppBundle\Security\FormAuthenticator
          arguments: ["@router"]

这个服务引用了FormAuthenticator类：

namespace AppBundle\Security;

use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\RouterInterface;
use Symfony\Component\Security\Core\Exception\CustomUserMessageAuthenticationException;
use Symfony\Component\Security\Core\Exception\UsernameNotFoundException;
use Symfony\Component\Security\Core\Security;
use Symfony\Component\Security\Core\User\InMemoryUserProvider;
use Symfony\Component\Security\Core\User\UserInterface;
use Symfony\Component\Security\Guard\AbstractGuardAuthenticator;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Exception\AuthenticationException;
use Symfony\Component\Security\Core\User\UserProviderInterface;

class FormAuthenticator extends AbstractGuardAuthenticator
{

  /**
   * @var \Symfony\Component\Routing\RouterInterface
   */
  private $router;

  /**
   * Default message for authentication failure.
   *
   * @var string
   */
  private $failMessage = 'Invalid credentials';

  /**
   * Creates a new instance of FormAuthenticator
   */
  public function __construct(RouterInterface $router) {
    $this->router = $router;
  }

  /**
   * {@inheritdoc}
   */
  public function getCredentials(Request $request)
  {
    if ($request->getPathInfo() != '/login' || !$request->isMethod('POST')) {
      return;
    }

    return array(
      'username' => $request->request->get('username'),
      'password' => $request->request->get('password'),
    );
  }

  /**
   * {@inheritdoc}
   */
  public function getUser($credentials, UserProviderInterface $userProvider)
  {
    if (!$userProvider instanceof InMemoryUserProvider) {
      return;
    }

    try {
      return $userProvider->loadUserByUsername($credentials['username']);
    }
    catch (UsernameNotFoundException $e) {
      throw new CustomUserMessageAuthenticationException($this->failMessage);
    }
  }

  /**
   * {@inheritdoc}
   */
  public function checkCredentials($credentials, UserInterface $user)
  {
    if ($user->getPassword() === $credentials['password']) {
      return true;
    }
    throw new CustomUserMessageAuthenticationException($this->failMessage);
  }

  /**
   * {@inheritdoc}
   */
  public function onAuthenticationSuccess(Request $request, TokenInterface $token, $providerKey)
  {
    $url = $this->router->generate('homepage');
    return new RedirectResponse($url);
  }

  /**
   * {@inheritdoc}
   */
  public function onAuthenticationFailure(Request $request, AuthenticationException $exception)
  {
    $request->getSession()->set(Security::AUTHENTICATION_ERROR, $exception);
    $url = $this->router->generate('login');
    return new RedirectResponse($url);
  }

  /**
   * {@inheritdoc}
   */
  public function start(Request $request, AuthenticationException $authException = null)
  {
    $url = $this->router->generate('login');
    return new RedirectResponse($url);
  }

  /**
   * {@inheritdoc}
   */
  public function supportsRememberMe()
  {
    return false;
  }
}

尽管他看起来似乎很多，其实不然。让我们一步一步去了解发生了什么事情。

首先，这个文件就在我们bundle的Security文件夹下，这个是一个个人习惯的选择，你随意。然后，我们继承AbstractGuardAuthenticator，因为他已经实现了GuardAuthenticatorInterface接口所有必须要实现接口的方法。如果我们需要一个特定的token类来完成我们的验证，我们仅仅需要实现这个接口极其createAuthenticatedToken方法。现在我们不需要。

实现这个接口的方法是问题的关键，验证都在这里，这个包括当一个用户访问到授权或者拒绝访问所有流程。

我们从这个getCredentials()方法开始，得到每个请求。这个方法的目的是从请求获取凭证数据并返回，或者返回null（会拒绝访问，或者允许其他验证器提供凭证，或者调用start()方法）。如果是这个案例：凭证是通过/login的提交post数据，我们会获得到提交的用户名和密码，并返回一个数组。

如果getCredentials()方法没有返回空，则顺利进入下一个方法getUser().getUser()负责加载用户，主要根据前面getCredentials()方法获得的凭证来获得用户。使用默认的用户提供器（我们案例里的InMemory提供器），基于用户名返回要加载的用户。我们也可以在这里返回null，他会触发验证失败，我们也可以选择CustomUserMessageAuthenticationException去指定我们自定义的失败消息。

如果上面用户被获取到并返回，这个checkCredentials方法就开始生效。这个方法的目的是核查传入的凭证和找到的用户是否匹配。更上面一样的道理，我们返回null或者抛出一个异常，验证失败。

此时，如果凭证匹配用户就可以登陆了。在这种情况下，onAuthenticationSuccess()方法被调用，他能做我们想做的事情。例如我们的案例，重定向到主页上就死一个很好的主意。相反的，如果验证失败，onAuthenticationFailure()方法就会被调用。我们需要做的就是重定向到/login页面，我们会把最后验证的错误信息放在session中，在表单模板显示出来。

start方法是Guard系统（或者应用）的切入点。这个方法是当用户尝试访问一个需要验证的页面时，他没有通过getCredentials()方法返回有效凭证，就会调用这个方法。在我们案例中就是如果有人试图访问主页，getCredentials()获取不到有用的请求，返回null，没有凭证。我们就将他重定向到/login页面，让他登录后访问主页。

让我们想象一下其他例子：基于token的验证。在这种情况下，每个请求需要包含一个token，来验证用户。这意味着getCredentials()将总能返回凭证。如果没有，start()方法将返回一个响应，拒绝访问。

最后，一个方法是负责标记remember-me功能的。在我们的例子中，没有使用它，所以返回false。关于Remember-Me的更多信息请查看symfony cookbook。

总结

我们现在使用Guard组件创建了一个全功能的登录系统。还有我们上面刚刚提到的token验证的例子，他与我们今天文章主要介绍的一起工作。可以存在多个身份验证器：

guard:
                authenticators:
                    - form_authenticator
                    - token_authenticator
                entry_point: form_authenticator

如果我们配置多个验证器，我们需要去指定哪一个是entry point（当一个用户尝试访问一个资源但是没有提供凭证，start()方法将会被调用）.

也就是说，我们创建多个验证器，我们提交的数据符合其中的一个即可通过验证，如果都不符合，会调用entry_point指定验证器的start()方法。

注意：Guard并不替换任何的symfony验证，只是补充。现有的将会继续工作。例如，form_login或者simple_form，我们之前使用过的，他们都将继续工作。

在symfony3.0中使用Guard很容易的完成身份验证，首发于Symfony中文教程。