所以我们要在User entity中添加一个字段roles，并且把它设置成json_array类型：

// src/Acme/UserBundle/Entity/User.php
// ...

/**
 * @ORM\Column(type="json_array")
 */
private $roles = array();

json_array()允许我们存储一个字符串数组到一个字段里。在数据库中，这些数组被存储为JSON字符串。Doctrine来负责array和JSON之间的转换工作。

现在我们要更新getRoles()方法，并添加setRoles方法：

public function getRoles()
{
    return $this->roles;
}

public function setRoles(array $roles)
{
    $this->roles = $roles;

    // allows for chaining
    return $this;
}

很酷，但是现在的方式，用户的用户角色很可能为空。他们变成了僵尸用户，他们能够登录，但不能访问页面，我们不能让这种事情发生。

应该在getRoles()添加一些逻辑，来保证每个用户都有ROLE_USER。

public function getRoles()
{
    $roles = $this->roles;
    $roles[] = 'ROLE_USER';

    return array_unique($roles);
}

更新一下数据库

php app/console doctrine:schema:update --force

让我们添加一个ROLE_ADMIN角色的用户

// src/Acme/UserBundle/DataFixtures/ORM/LoadUsers.php
// ...

public function load(ObjectManager $manager)
{
    // ...
    $manager->persist($user);

    $admin = new User();
    $admin->setUsername('wayne');
    $admin->setPassword($this->encodePassword($admin, 'waynepass'));
    $admin->setRoles(array('ROLE_ADMIN'));
    $manager->persist($admin);

    $manager->flush();
}

运行下面命令添加数据

php app/console doctrine:fixtures:load

现在我们用管理员登陆，debug条会显示我们有ROLE_USER和ROLE_ADMIN角色。

使用AdvancedUserBundle禁用不活跃用户

我们可以对一些不怎么来网站的用户进行禁用操作。

添加一个isActive的boolean字段到User entity。如果这个字段为假，那么程序会阻止用户进行身份验证。不要忘了在命令行运行 doctrine:generate:entities 来生成get和set方法：

/ src/Acme/UserBundle/Entity/User.php
// ...

/**
 * @var bool
 *
 * @ORM\Column(type="boolean")
 */
private $isActive = true;

// ...
// write or generate your getIsActive and setIsActive methods...

在那之后，更新我们的数据库字段

php app/console doctrine:schema:update --force

现在isActive字段已经存在了，但是它还不能的在登陆中使用。为了使他能工作，要将User类的UserInterface替换成implements AdvancedUserInterface；

// src/Acme/UserBundle/Entity/User.php
// ...

use Symfony\Component\Security\Core\User\AdvancedUserInterface;

class User implements AdvancedUserInterface
{
    // ...
}

这里 AdvancedUserInterface继承UserInterface。

新的接口是一个更强大的UserInterface他需要四个额外的方法。如果这些方法返回false，Symfony将阻止用户登录。为了证明这一点，除了isAccountNonLocked都返回true：

// src/Acme/UserBundle/Entity/User.php
// ...

public function isAccountNonExpired()
{
    return true;
}

public function isAccountNonLocked()
{
    return false;
}

public function isCredentialsNonExpired()
{
    return true;
}

public function isEnabled()
{
    return true;
}

现在登录不太好玩了：我们堵住了有用的信息。

这里所有的方法都在做同样的事情：就是阻止登陆。如果你想你可以翻译每个用户带来的不同信息。设置每一个都为true，除了isEnabled。让他返回isActive属性的值：

/ src/Acme/UserBundle/Entity/User.php
// ...

public function isAccountNonLocked()
{
    return true;
}

public function isEnabled()
{
    return $this->getIsActive();
}

如果isActive为false，这应该阻止用户登录。

我们更改不活跃的用户：

// src/Acme/UserBundle/DataFixtures/ORM/LoadUsers.php
// ...

public function load(ObjectManager $manager)
{
    // ...
    $admin->setIsActive(false);
    // ...
}

运行命令：

php app/console doctrine:fixtures:load

当我们尝试登录，程序自动阻止。爽！

哈哈，学会了吧。我们可以还原程序了，让用户能够登录进来。

KU案例2之10给数据库中的用户添加角色，首发于Symfony中文教程。

Doctrine查询对象

在第二天的内容中我们定义了这样一个需求（requirements）：“在Job首页显示最近发布的和在有效期内的Job信息列表”。我们现在在首页中显示的是数据库中全部的Job数据，而没有考虑到不需要在首页中显示已过期的Job信息。

// src/Ibw/JobeetBundle/Controller/JobController.php
// ...

class JobController extends Controller
{
    public function indexAction()
    {
        $em = $this->getDoctrine()->getManager();

        $entities = $em->getRepository('IbwJobeetBundle:Job')->findAll();

        return $this->render('IbwJobeetBundle:Job:index.html.twig', array(
            'entities' => $entities
        ));

 // ...
}

一个在有效期限内的Job数据就代表着这个Job信息发布的日期在30天之内。$entities = $em->getRepository('IbwJobeetBundle')->findAll()这行代码是从数据库中取出所有的Job数据，因为我们并没有给查询指定任何的条件。

现在我们来做些修改，我们希望取出的是在有效期内的Job数据：

// src/Ibw/JobeetBundle/Controller/JobController.php
public function indexAction()
{
    $em = $this->getDoctrine()->getManager();

    $query = $em->createQuery(
        'SELECT j FROM IbwJobeetBundle:Job j WHERE j.created_at > :date'
    )->setParameter('date', date('Y-m-d H:i:s', time() - 86400 * 30));
    $entities = $query->getResult();

    return $this->render('IbwJobeetBundle:Job:index.html.twig', array(
        'entities' => $entities
    ));
}

调试Doctrine生成的SQL

有时候查看Doctrine生成出来的SQL对我们调试Bug是很有帮助的。比如，我们可能在使用Doctrine进行数据库查询时得不到我们所期望的结果时，那么我们就很需要去查看Doctrine生成的SQL，并以此来对我们的代码进行排错。在开发环境（development）下，还好有Symfony的调试工具栏（浏览器页面的最下面的那条栏），我们能在调试栏中找到大量我们在调试过程中需要用到的信息，包括刚才所说的SQL调试（http://jobeet.local/app_dev.php）。

序列化对象

尽管上面的代码可以运行了，但这离完美还差很远呢，因为我们还没有考虑到另一个需求：“一个用户能够重新激活或者延续Job信息的期限多30天”。

在上面的代码中我们只依赖了created_at的值来取出不过期的Job数据，由于created_at代表的是Job的创建时间，如果我们还需要表示Job数据的过期时间，我们还要另外一些列（columns）。

如果你还记得我们在第三天的内容中描述的数据表结构的话，你肯定会记起我们还定义了一个expires_at列。由于我们还没在Fixture文件中设置expires_at的值，所以它们的值都是空的。我们需要的是，当一个Job被创建的时候，expires_at的值就会被设置成created_at值的30天之后。

每当我们需要在Doctrine对象被序列化到数据库中之前能够自动执行一些操作的时候，我们可以添加一个新的行为（action）到ORM映射文件的lifecycle callback区块中，就像我们之前对created_at列进行的操作：

# src/Ibw/JobeetBundle/Resources/config/doctrine/Job.orm.yml
# ...
    # ...
    lifecycleCallbacks:
        prePersist: [ setCreatedAtValue, setExpiresAtValue ]
        preUpdate: [ setUpdatedAtValue ]

现在我们需要重新生成实体类（entity class），这样Doctrine就会在Job实体类中添加一个setExpiresAtValue()函数：

php app/console doctrine:generate:entities IbwJobeetBundle

打开src/Ibw/JobeetBundle/Entity/Job.php文件，我们来编辑setExpiresAtValue()函数：

// src/Ibw/JobeetBundle/Entity/Job.php
// ...

class Job
{
    // ... 

    public function setExpiresAtValue()
    {
        if(!$this->getExpiresAt()) {
            $now = $this->getCreatedAt() ? $this->getCreatedAt()->format('U') : time();
            $this->expires_at = new \DateTime(date('Y-m-d H:i:s', $now + 86400 * 30));
        }
    }
}

好，现在让我们来用expires_at列来替换created_at列来取出未过期的Job数据：

// src/Ibw/JobeetBundle/Controller/JobController.php
// ...

    public function indexAction()
    {
        $em = $this->getDoctrine()->getManager();

        $query = $em->createQuery(
            'SELECT j FROM IbwJobeetBundle:Job j WHERE j.expires_at > :date'
    )->setParameter('date', date('Y-m-d H:i:s', time()));
        $entities = $query->getResult();

        return $this->render('IbwJobeetBundle:Job:index.html.twig', array(
            'entities' => $entities
        ));
    }

// ...

加入更多的Fixtures

现在我们刷新浏览器中的Job首页，我们不会看到页面有任何的改变，因为我们之前加入到数据库中的Job数据都才仅仅发布了几天，所以现在数据库中的Job数据都是在有效期内的。让我们在Fixture文件中加入一些已过期的（expired）的Job数据吧：

// src/Ibw/JobeetBundle/DataFixtures/ORM/LoadJobData.php
// ...

    public function load(ObjectManager $em)
    {
        $job_expired = new Job();
        $job_expired->setCategory($em->merge($this->getReference('category-programming')));
        $job_expired->setType('full-time');
        $job_expired->setCompany('Sensio Labs');
        $job_expired->setLogo('sensio-labs.gif');
        $job_expired->setUrl('http://www.sensiolabs.com/');
        $job_expired->setPosition('Web Developer Expired');
        $job_expired->setLocation('Paris, France');
        $job_expired->setDescription('Lorem ipsum dolor sit amet, consectetur adipisicing elit.');
        $job_expired->setHowToApply('Send your resume to lorem.ipsum [at] dolor.sit');
        $job_expired->setIsPublic(true);
        $job_expired->setIsActivated(true);
        $job_expired->setToken('job_expired');
        $job_expired->setEmail('job@example.com');
        $job_expired->setCreatedAt(new \DateTime('2005-12-01'));

        // ...

        $em->persist($job_expired);
        // ...
    }

// ...

现在我们来重新加载Fixtures，然后刷新浏览器，确保过期的Job信息不会被显示出来：

php app/console doctrine:fixtures:load

重构代码

尽管上面的代码已经能运行了，但我们所做得还是不够好，你能发现其中有什么问题吗？

Doctrine的查询代码不应该属于action（Controller层），它应该属于Model层。在MVC模式中，Model层定义的是业务逻辑，而Controller层则通过是Model层来从数据库中取出数据。现在我们来把之前从数据库中获取Job数据集合的代码从Controller层移到Model层吧。现在我们为Job实体类创建一个Repository类。

打开/src/Ibw/JobeetBundle/Resources/config/doctrine/Job.orm.yml，添加下面的代码：

Ibw\JobeetBundle\Entity\Job:
    type: entity
    repositoryClass: Ibw\JobeetBundle\Repository\JobRepository
    # ...

运行下面的命令，Doctrine能够帮我们生成Repository类：

php app/console doctrine:generate:entities IbwJobeetBundle

下一步我们来给JobRepository类添加一个方法：getActiveJobs()。这个方法可以取出有效期内的Job数据，并且按照expires_at的值进行排序（它还可以接受一个$category_id参数，它可以按分类来取出Job数据）。

// src/Ibw/JobeetBundle/Repository/JobRepository.php
namespace Ibw\JobeetBundle\Repository;

use Doctrine\ORM\EntityRepository;

/**
 * JobRepository
 *
 * This class was generated by the Doctrine ORM. Add your own custom
 * repository methods below.
 */
class JobRepository extends EntityRepository
{
    public function getActiveJobs($category_id = null)
    {
        $qb = $this->createQueryBuilder('j')
                   ->where('j.expires_at > :date')
                   ->setParameter('date', date('Y-m-d H:i:s', time()))
                   ->orderBy('j.expires_at', 'DESC');

        if ($category_id) {
            $qb->andWhere('j.category = :category_id')
               ->setParameter('category_id', $category_id);
        }

        $query = $qb->getQuery();

        return $query->getResult();
    }
}

现在action里面就可以使用刚才添加的getActiveJobs()方法了。

// src/Ibw/JobeetBundle/Controller/JobController.php
// ...

    public function indexAction()
    {
        $em = $this->getDoctrine()->getManager();

        $entities = $em->getRepository('IbwJobeetBundle:Job')->getActiveJobs();

        return $this->render('IbwJobeetBundle:Job:index.html.twig', array(
            'entities' => $entities
        ));
    }

// ...

上面重构后的代码比起之前的未重构代码有如下优点：

• 获取有效期内的Job数据的代码现在位于Model层中
• JobController::indexAction()中的代码更少了，可读性也提高了
• getActiveJobs()方法可以被重用
• 更加容易地对model的代码进行测试

首页中的Categories

根据我们第二天内容中的需求，Job信息能够按照分类进行显示。直到现在我们都还没考虑到对Job信息进行分类显示。按照第二天内容中的需求，我们需要在首页中按照不同的分类来显示Job信息。首先，我们需要获得包含有未过期的Job数据的所有分类。

为Category实体创建一个Repository类：

# src/Ibw/JobeetBundle/Resources/config/doctrine/Category.orm.yml
Ibw\JobeetBundle\Entity\Category:
    type: entity
    repositoryClass: Ibw\JobeetBundle\Repository\CategoryRepository
    #...

生成Repository类：

php app/console doctrine:generate:entities IbwJobeetBundle

打开src/Ibw/JobeetBundle/Repository/CategoryRepository.php文件，添加getWithJobs()方法：

// src/Ibw/JobeetBundle/Repository/CategoryRepository.php
namespace Ibw\JobeetBundle\Repository;

use Doctrine\ORM\EntityRepository;

/**
 * CategoryRepository
 *
 * This class was generated by the Doctrine ORM. Add your own custom
 * repository methods below.
 */
class CategoryRepository extends EntityRepository
{
    public function getWithJobs()
    {
        $query = $this->getEntityManager()->createQuery(
            'SELECT c FROM IbwJobeetBundle:Category c LEFT JOIN c.jobs j WHERE j.expires_at > :date'
        )->setParameter('date', date('Y-m-d H:i:s', time()));

        return $query->getResult();
    }   
}

同时我们需要修改indexAction()方法：

// src/Ibw/JobeetBundle/Controller/JobController.php
// ...

    public function indexAction()
    {
        $em = $this->getDoctrine()->getManager();

        $categories = $em->getRepository('IbwJobeetBundle:Category')->getWithJobs();

        foreach($categories as $category) {
            $category->setActiveJobs($em->getRepository('IbwJobeetBundle:Job')->getActiveJobs($category->getId()));
        }

        return $this->render('IbwJobeetBundle:Job:index.html.twig', array(
            'categories' => $categories
        ));
    }

// ...

我们在上面的代码中可以看到Category有个setActiveJobs()方法，那么现在我们来修改这个方法：

// src/Ibw/JobeetBundle/Entity/Category.php
class Category
{
    // ...

    private $active_jobs;

    // ...

    public function setActiveJobs($jobs)
    {
        $this->active_jobs = $jobs;
    }

    public function getActiveJobs()
    {
        return $this->active_jobs;
    }
}

在模板中，我们需要通过迭代变量categories的值来显示所有的Job数据：

<!-- src/Ibw/JobeetBundle/Resources/views/Job/index.html.twig -->
<!-- ... -->
{% block content %}
    <div id="jobs">
        {% for category in categories %}
            <div>
                <div class="category">
                    <div class="feed">
                        <a href="">Feed</a>
                    </div>
                    <h1>{{ category.name }}</h1>
                </div>
                <table class="jobs">
                    {% for entity in category.activejobs %}
                        <tr class="{{ cycle(['even', 'odd'], loop.index) }}">
                            <td class="location">{{ entity.location }}</td>
                            <td class="position">
                                <a href="{{ path('ibw_job_show', { 'id': entity.id, 'company': entity.companyslug, 'location': entity.locationslug, 'position': entity.positionslug }) }}">
                                    {{ entity.position }}
                                </a>
                            </td>
                             <td class="company">{{ entity.company }}</td>
                        </tr>
                    {% endfor %}
                </table>
            </div>
        {% endfor %}
    </div>
{% endblock %}

限制结果行数

我们现在需要限制Job信息列表中显示的行数为10行。实现这个功能非常简单，我们来给JobRepository::getActiveJobs()方法添加一个$max参数：

// src/Ibw/JobeetBundle/Repository/JobRepository.php
public function getActiveJobs($category_id = null, $max = null)
{
    $qb = $this->createQueryBuilder('j')
        ->where('j.expires_at > :date')
        ->setParameter('date', date('Y-m-d H:i:s', time()))
        ->orderBy('j.expires_at', 'DESC');

    if($max) {
        $qb->setMaxResults($max);
    }

    if($category_id) {
        $qb->andWhere('j.category = :category_id')
            ->setParameter('category_id', $category_id);
    }

    $query = $qb->getQuery();

    return $query->getResult();
}

修改indexAction()方法中的代码，我们需要使用$max参数来调用getActiveJobs()方法：

// src/Ibw/JobeetBundle/Controller/JobController.php
// ...

public function indexAction()
{
    $em = $this->getDoctrine()->getManager();

    $categories = $em->getRepository('IbwJobeetBundle:Category')->getWithJobs();

    foreach($categories as $category)
    {
        $category->setActiveJobs($em->getRepository('IbwJobeetBundle:Job')->getActiveJobs($category->getId(), 10));
    }

    return $this->render('IbwJobeetBundle:Job:index.html.twig', array(
        'categories' => $categories
    ));
}

// ...

自定义配置

在JobController::indexAction()方法中，我们对返回Job数据的行数（$max = 10）进行了硬编码（hardcode），我们需要让返回行数的值是可配置的。在Symfony中，我们可以在app/config/config.yml文件中的parameters区块中自定义一些配置（如果parameters区块不存在的话，那么我们也可以自行创建它）。

# app/config/config.yml
# ...

parameters:
    max_jobs_on_homepage: 10

定义好后我们就可以在Controller中访问它们的值了：

// src/Ibw/JobeetBundle/Controller/JobController.php
// ...

    public function indexAction()
    {
        $em = $this->getDoctrine()->getManager();

        $categories = $em->getRepository('IbwJobeetBundle:Category')->getWithJobs();

        foreach($categories as $category) {
            $category->setActiveJobs($em->getRepository('IbwJobeetBundle:Job')->getActiveJobs($category->getId(), $this->container->getParameter('max_jobs_on_homepage')));
        }

        return $this->render('IbwJobeetBundle:Job:index.html.twig', array(
            'categories' => $categories
        ));
    }

// ...

动态Fixtures

对于上面所做的修改，我们还不能在页面中看到有什么变化，因为现在我们的数据库中只有很少量的Job数据。现在我们需要在Fixture中批量添加Job数据。我们可选择手动复制之前已存在的代码来重复进行生成Job数据，但我们有更好的办法。我们需要引起注意的是，重复的代码给人的感觉就是很差，甚至在Fixture文件中出现重复的代码：

// src/Ibw/JobeetBundle/DataFixtures/ORM/LoadJobData.php
// ...

public function load(ObjectManager $em)
{
    // ...

    for($i = 100; $i <= 130; $i++)
    {
        $job = new Job();
        $job->setCategory($em->merge($this->getReference('category-programming')));
        $job->setType('full-time');
        $job->setCompany('Company '.$i);
        $job->setPosition('Web Developer');
        $job->setLocation('Paris, France');
        $job->setDescription('Lorem ipsum dolor sit amet, consectetur adipisicing elit.');
        $job->setHowToApply('Send your resume to lorem.ipsum [at] dolor.sit');
        $job->setIsPublic(true);
        $job->setIsActivated(true);
        $job->setToken('job_'.$i);
        $job->setEmail('job@example.com');

        $em->persist($job);
    }

    // ... 
    $em->flush();
}

// ...

现在用doctrine:fixtures:load命令来重新加载Fixture，观察Programming分类下的Job信息行数是否为10行：

过期的Job页面

如果一个Job不在有效期限内了，那么它将是不再可能被用户访问到的，即使用户知道它所在的URL也不行。我们可以尝试着访问过期的Job信息的页面（获得过期的Job信息的id的方法：select id, token from job where expires_at < NOW()，然后把获得的id替换下面URL中ID的值）:

/app_dev.php/job/sensio-labs/paris-france/ID/web-developer-expired

每当用户访问过期的Job信息页面时，我们应该让用户重定向到404页面。现在我们来给JobRepository添加一个方法：

// src/Ibw/JobeetBundle/Repository/JobRepository.php
// ...

public function getActiveJob($id)
{
    $query = $this->createQueryBuilder('j')
        ->where('j.id = :id')
        ->setParameter('id', $id)
        ->andWhere('j.expires_at > :date')
        ->setParameter('date', date('Y-m-d H:i:s', time()))
        ->setMaxResults(1)
        ->getQuery();

    try {
        $job = $query->getSingleResult();
    } catch (\Doctrine\Orm\NoResultException $e) {
        $job = null;
    }

    return $job;
}

 如果没有结果被返回，那么getSingleResult()方法会抛出Doctrine\ORM\NoResultException异常；如果返回的结果不止一个，那么getSingleResult()方法会抛出Doctrine\ORM\NonUniqueResultException异常。如果你使用getSingleResult()方法，那么请用try…catch语句包含它，以至于确保所返回的结果集只有一行数据。

现在修改JobController::showAction()方法：

// src/Ibw/JobeetBundle/Controller/JobController.php
// ...

$entity = $em->getRepository('IbwJobeetBundle:Job')->getActiveJob($id);

// ...

现在我们去访问一个已过期的Job信息页面，我们会被重定向到404页面：

好了，我们今天就到这吧。我们明天会开始实现Category页面。

原文链接：http://www.intelligentbee.com/blog/2013/08/12/symfony2-jobeet-day-6-more-with-the-model/

jobeet第六天:更多的数据模型，首发于Symfony中文教程。

该方法的第一个步骤中，知道该安全系统识别用户是谁，要求用户提交某种身份识别。这就是所谓的authentication（认证），这意味着该系统试图找出你是谁。
一旦系统知道了你是谁，进入下一个步骤来确定是否能够访问指定的资源。这个过程被称为authorization（授权），它的意思是系统正在检查，看看是否有权限来执行某一动作。

最好的学习方法是看一个例子，假设你想在您的应用程序中使用HTTP基本身份验证。

Symfony2的安全组件作为一个独立的PHP库可以用于任何PHP项目中。

基本的例子：HTTP Authentication（认证）

安全组件可以通过应用程序配置进行配置。实际上，最标准的安全设置只是使用了正常的配置。
下面的配置是告诉symfony，对于任何匹配 /admin/* 的URL都需要保护，并要求使用基本的HTTP Authentication（认证）（即老派的用户名／密码对话框）来询问用户凭证。

# app/config/security.yml
security:
    firewalls:
        secured_area:
            pattern:   ^/
            anonymous: ~
            http_basic:
                realm: "Secured Demo Area"

    access_control:
        - { path: ^/admin/, roles: ROLE_ADMIN }
        # Include the following line to also secure the /admin path itself
        # - { path: ^/admin$, roles: ROLE_ADMIN }

    providers:
        in_memory:
            memory:
                users:
                    ryan:  { password: ryanpass, roles: 'ROLE_USER' }
                    admin: { password: kitten, roles: 'ROLE_ADMIN' }

    encoders:
        Symfony\Component\Security\Core\User\User: plaintext

 一个标准的Symfony2发布将安全配置单独放入单个文件（如：app/config/security.yml）。如果你没有单独的安全文件，你可以直接将配置放入你的主配置文件中（如app/config/config.yml）。

该配置最终结果是一个全功能的安全系统，如下所示：

• 有两个用户在系统中（ryan和admin）；
• 用户可以通过基本的HTTP身份验证提示来验证自己；
• 任何匹配/admin/*的URL都会经过安全认证，只有admin用户可以访问它；
• 所有不匹配/admin/*的URL可以被所有用户访问（永远不会提示用户登录）；

让我们简要地看看安全是如何工作的，以及配置的每一部分是如何在一起工作的。

Security怎样工作：认证和授权

Symfony2安全系统的工作就是确定用户是谁（认证）然后检查看看用户是否有访问特定资源或URL的权限。

防火墙（认证）

当一个用户将一个请求发向一个被防火墙保护的URL时，安全系统就被激活了。防火墙的工作就是要确保用户是不是需要被认证，如果需要的话，发送一个响应返回给用户去启动认证过程。
当传入请求的URL匹配防火墙的正则表达式pattern(模式)时，防火墙被激活。在本例中，pattern（模式） (^/)将匹配任何传入的请求。然而，其实防火墙被激活也没有意义，任何URL都不会使HTTP认证用户名和密码对话框出现。例如，任何用户都可以访问/foo，而不会提示要去认证。

您也可以匹配的请求的其他信息（如主机和方法）的请求。欲了解更多信息和示例，阅读 如何限制防火墙到一个特定的请求。

之所以这样首先是因为通过anonymous（匿名）配置参数，防火墙允许匿名用户通过。换句话说，防火墙不要求用户立刻进行认证。其次是因为没有特定的role（角色）需要访问/foo（下面的access_control部分），请求甚至可以在没有要求用户认证的情况下完成。
如果你删除了anonymous（匿名）关键词，那么防火墙总是要求用户立即认证的。

访问控制（授权）

然而如果用户请求/admin/foo，那么处理过程是不同的。这是因为access_control配置部指出任何匹配正则表达式^/admin（如/admin或任何匹配/admin/*的URL）都需要ROLE_ADMIN角色。角色是大多数授权的基础：如果用户拥有ROLE_ADMIN角色，用户可以访问/admin/foo。

像前面一样，当用户最初发送请求时，防火墙并不要求任何身份。然而当访问控制层拒绝用户访问（因为匿名用户没有ROLE_ADMIN用户）时，防火墙接管该过程，并启动认证进程。认证依赖你所用的认证机制。例如，如果你使用表单登录认证方式，用户将被重定向到登录页面。如果你使用的是HTTP认证，用户将被发送HTTP的401响应，以便用户可以看到用户名密码对话框。
用户现在有机会提交它的证书给应用程序。如果证书是有效的，那么原始请求会被重发。

在本例中，用户ryan成功通过防火墙认证。但因为ryan没有拥有ROLE_ADMIN角色，它仍然被拒绝访问/admin/foo。最终这意味着用户将看到消息说明访问被拒绝。
当Symfony2拒绝用户访问时，用户可以看到一个错误页面并收到一个HTTP的403状态码（Forbidden）。你可以根据食谱（cookbook）错误页面中的自定义403错误页内容来自定义拒绝访问页。

最后，如果admin用户请求/admin/foo，相拟的进程会发生。但是在认证之后，访问控制层将让请求通过：

当用户请求一个受保护资源时产生的请求流是十分简单的，但相当灵活。正如你稍后将看到的那样，认证可以通过多样方式来处理，包括通过表单登录、X.509证书或通过Twitter来认证用户。无论认证的模式如何，请求流总是相同的：

1. 用户访问受限资源；
2. 应用程序将用户重定向给登录表单；
3. 用户提交它的证书（如：用户名／密码）；
4. 防火墙认证用户；
5. 认证用户重发原始请求。

确切的过程实际取决于你所使用的认证机制。举个例子，当使用表单登录时，用户提交它的证书到一个处理表单的URL（如 /login_check），然后重定向到最初请求的URL（如 /admin/foo）。但是如果是HTTP认证，用户将直接提供它的证书到原始URL（如 /admin/foo），然后在同一请求中将页面返回给用户（即：不进行重定向）
这些特质不会引起任何问题，但记住它们是有好处的。

你也将在稍后学到在Symfony2中如何保证其它事物的安全，包括特定的控制器、对象、甚至是PHP方法。

使用传统的登录表单

在本节，security.yml文件中，继续使用硬编码定义用户，然后你需要学习怎样去创建基本的登录表单。
如果从数据库中加载用户，你需要阅读How to Load Security Users from the Database (the Entity Provider)。
通过阅读这篇文章的这一节,您可以从数据库中加载用户创建一个完整的登录表单系统。

在目前为止，你已经看到如何将你的应用程序放置在防火墙下，然后根据规则限制访问某些区域。通过使用HTTP认证，你可以毫不费力地进入所有浏览器都可以提供的用户名／密码框。然而，Symfony2支持许多对话框以外的认证机制。所有这一切的细节，可参见安全配置参考。
在本节中，你将让用户通过一个传统的HTML登录表单来增强这一过程。
首先，在你的防火墙下启动表单登录：

# app/config/security.yml
security:
    firewalls:
        secured_area:
            pattern:   ^/
            anonymous: ~
            form_login:
                login_path: login
                check_path: login_check

 如果你不需要自定义你的login_path或check_path的值（这里的值是缺省值），你可以缩写你的配置：

form_login: ~

 

现在，当安全系统启动认证过程时，它将用户重定向到登录表单（默认情况下是/login）。实现这个登录表单。首先创建两个路由：一个login路由显示登录表单（如：/login），一个login_check将处理登录表单的提交（如：/login_check）：

# app/config/routing.yml
login:
    path:     /login
    defaults: { _controller: AcmeSecurityBundle:Security:login }
login_check:
    path: /login_check

 你不需要为/login_check的URL实现控制器，因为防火墙会自动捕捉和处理这一URL上的任何表单提交。然而，你一定要有个路由（如下所示）URL，以及一个用于注销的路径（查看本页 Logging Out）。

注意，login路由匹配login_path的配置值，因为在那里安全系统将进行重定向需要登录的用户。

下一步，创建显示登录表单的控制器：

// src/Acme/SecurityBundle/Controller/SecurityController.php;
namespace Acme\SecurityBundle\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Security\Core\Security;

class SecurityController extends Controller
{
    public function loginAction(Request $request)
    {
        $session = $request->getSession();

        // get the login error if there is one
        if ($request->attributes->has(Security::AUTHENTICATION_ERROR)) {
            $error = $request->attributes->get(
                Security::AUTHENTICATION_ERROR
            );
        } elseif (null !== $session && $session->has(Security::AUTHENTICATION_ERROR)) {
            $error = $session->get(Security::AUTHENTICATION_ERROR);
            $session->remove(Security::AUTHENTICATION_ERROR);
        } else {
            $error = '';
        }

        // last username entered by the user
        $lastUsername = (null === $session) ? '' : $session->get(Security::LAST_USERNAME);

        return $this->render(
            'AcmeSecurityBundle:Security:login.html.twig',
            array(
                // last username entered by the user
                'last_username' => $lastUsername,
                'error'         => $error,
            )
        );
    }
}

不要让这个控制器迷惑你。正如你将稍后看到的那样，当用户提交表单时，安全系统自动为你处理表单提交。如果用户提交了一个非法的用户名或密码，控制器会从安全系统中读到表单提交的错误，以便返回给用户显示。

换句话说，你的工作是显示登录表单以及可能发生的错误，但安全系统自身检查提交的用户名和密码，并对该用户进行认证。

最后，创建相应的表单：

{# 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" />

    {#
        If you want to control the URL the user
        is redirected to on success (more details below)
        <input type="hidden" name="_target_path" value="/account" />
    #}

    <button type="submit">login</button>
</form>

 此登录表单目前无法防止CSRF攻击，阅读 在登录窗体使用CSRF保护如何保护您的登录表单

被送入模板的错误变量是AuthenticationException的实例。它也许包含更多关于认证失败的信息，甚至是敏感信息。所以它使用的非常广泛！

表单有着非常少的要求。首先，通过提交表单到/login_check（通过login_check路由），安全系统自动为你截取表单提交并进行表单处理。其次，安全系统预期被提交的表单项是_username和_password（这些表单项名可以被配置）。

这是这样！当你提交表单时，安全系统将自动检查用户的证书，要么认证通过用户，要么将用户重定向到登录表单以显示错误信息。

回顾整个过程：

1. 用户尝试访问受限用户；
2. 防火墙通过将用户重定向到登录表单（/login）并启动认证过程；
3. 在本例中，/login页通过创建路由和控制器来渲染登录页面；
4. 用户提交登录表单到/login_check；
5. 安全系统拦截请求，检查用户提交的证书，如果正确的话就认证通过用户，反之则将用户送回登录页面。

默认情况下，如果提交的证书是正确的，用户将被重定向到被请求的原始页（如：/admin/foo）。如果用户本来就直接访问的login页面，它将被重定向到主页。这可以允许你去定制，例如，重定向用户到指定的URL。
关于这个的更多细节，以及如何自定义表单登录过程，请参见如何自定义你的表单登录。

避免常见错误
在设置登录表单时，注意一些常见的陷阱。
1. 创建正确的路由
首先，确保你已经正确地定义了/login和/login_check路由，它们对应着login_path和check_path配置值。这里的一个错误配置可能会将你重定向到404页，而非登录页面，或者提交登录表单之后什么事情也没发生（你只是一遍又一遍地看到登录页面）。
2. 确保登录页面是不安全的
同样，也需要确保登录页面是不要求任何角色就可以查看的。例如，下面的配置，为所有的URL要求ROLE_ADMIN角色（包括/login的URL），会引起循环重定义的：

# app/config/security.yml

# ...
access_control:
    - { path: ^/, roles: ROLE_ADMIN }

在/login的URL上删除访问控制以修复该问题：

# app/config/security.yml

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

同样，如果你的防火墙不允许匿名用户的话，你也需要创建一个特殊的防火墙来让匿名用户使用登录页：

# app/config/security.yml

# ...
firewalls:
    login_firewall:
        pattern:   ^/login$
        anonymous: ~
    secured_area:
        pattern:    ^/
        form_login: ~

3. 确保“/login_check”在防火墙之后

接下来，确保你check_path的URL（如：/login_check）在你登录表单的防火墙之后（在本例中，单个防火墙匹配所有URL，包含/login_check）。如果/login_check没有匹配任何防火墙，你将得到不能为路径“/login_check”找到控制器的异常。

4. 多个防火墙不能共享安全内容

如果你使用多重防火墙，并且你在针对一个防火墙进行认证，那么你将不会再自动针对其它的防火墙进行认证。不同的防火墙就象不同的安全系统。这也是为什么对于大多数应用程序而言，有一个主要的防火墙就足够了的原因。

5.路由错误页面不包含在防火墙里

未完待续中…..

第十三章：安全Security，首发于Symfony中文教程。

你可以将上传文件的处理集成到Entity的生命周期中（如创建，修改和删除时调用）。

在这种情况下的好处，在Doctrine中创建、修改和删除数据时，上传文件和删除文件也会自动完成（必须在控制器中做任何操作）

基本设置

创建一个简单的Doctrine实体类：

// src/Acme/DemoBundle/Entity/Document.php
namespace Acme\DemoBundle\Entity;

use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Validator\Constraints as Assert;

/**
 * @ORM\Entity
 */
class Document
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    public $id;

    /**
     * @ORM\Column(type="string", length=255)
     * @Assert\NotBlank
     */
    public $name;

    /**
     * @ORM\Column(type="string", length=255, nullable=true)
     */
    public $path;

    public function getAbsolutePath()
    {
        return null === $this->path
            ? null
            : $this->getUploadRootDir().'/'.$this->path;
    }

    public function getWebPath()
    {
        return null === $this->path
            ? null
            : $this->getUploadDir().'/'.$this->path;
    }

    protected function getUploadRootDir()
    {
        // the absolute directory path where uploaded
        // documents should be saved
        return __DIR__.'/../../../../web/'.$this->getUploadDir();
    }

    protected function getUploadDir()
    {
        // get rid of the __DIR__ so it doesn't screw up
        // when displaying uploaded doc/image in the view.
        return 'uploads/documents';
    }
}

该document实体有一个名称与文件相关联。这个path属性存储一个文件的相对路径并且在数据库中存储。这个getAbsolutePath()会返回一个绝对路径，getWebPath()会返回一个web路径，用于模板加入上传文件链接。

如果你还没有这样做的话，你应该阅读http://symfony.com/doc/current/reference/forms/types/file.html首先了解基本的上传过程。

如果您使用注释来验证规则（如本例所示），请确保你启用了注释验证（见http://symfony.com/doc/current/book/validation.html#book-validation-configuration）。

 

在处理一个实际的文件上传时，使用一个“虚拟”的file字段。例如，如果你在controller中直接构建一个form，他可能是这样的：

public function uploadAction()
{
    // ...

    $form = $this->createFormBuilder($document)
        ->add('name')
        ->add('file')
        ->getForm();

    // ...
}

下一步，创建file这个属性到你的Document类中并且添加一些验证规则：

use Symfony\Component\HttpFoundation\File\UploadedFile;

// ...
class Document
{
    /**
     * @Assert\File(maxSize="6000000")
     */
    private $file;

    /**
     * Sets file.
     *
     * @param UploadedFile $file
     */
    public function setFile(UploadedFile $file = null)
    {
        $this->file = $file;
    }

    /**
     * Get file.
     *
     * @return UploadedFile
     */
    public function getFile()
    {
        return $this->file;
    }
}

annotations

// src/Acme/DemoBundle/Entity/Document.php
namespace Acme\DemoBundle\Entity;

// ...
use Symfony\Component\Validator\Constraints as Assert;

class Document
{
    /**
     * @Assert\File(maxSize="6000000")
     */
    private $file;

    // ...
}

 当你使用File约束，symfony会自动猜测表单字段输入的是一个文件上传。这就是当你创建表单（->add(‘file’)）时，为什么没有在表单明确设置为文件上传的原因。

下面的控制器，告诉您如何处理全部过程：

// ...
use Acme\DemoBundle\Entity\Document;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Template;
use Symfony\Component\HttpFoundation\Request;
// ...

/**
 * @Template()
 */
public function uploadAction(Request $request)
{
    $document = new Document();
    $form = $this->createFormBuilder($document)
        ->add('name')
        ->add('file')
        ->getForm();

    $form->handleRequest($request);

    if ($form->isValid()) {
        $em = $this->getDoctrine()->getManager();

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

        return $this->redirect($this->generateUrl(...));
    }

    return array('form' => $form->createView());
}

以前的controller当提交name自动的存储Document实体，但是他不会做任何关于文件的事情并且path属性也将是空白。

处理文件上传一个简单的方法就是在entity持久化之前设置相应的path属性。在某一时刻处理文件上传时，要调用Document实体类一个upload()方法给path赋值。

if ($form->isValid()) {
    $em = $this->getDoctrine()->getManager();

    $document->upload();

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

    return $this->redirect(...);
}

这个upload()方法利用UploadedFile对象，是它提交后返回file字段：

public function upload()
{
    // the file property can be empty if the field is not required
    // 该file属性为空这个属性就不需要了
    if (null === $this->getFile()) {
        return;
    }

    // use the original file name here but you should
    // sanitize it at least to avoid any security issues
    //  这里你应该使用原文件名但是应该至少审核它避免一些安全问题
    // move takes the target directory and then the
    // target filename to move to
    // 将目标文件移动到目标目录
    $this->getFile()->move(
        $this->getUploadRootDir(),
        $this->getFile()->getClientOriginalName()
    );

    // set the path property to the filename where you've saved the file
    // 设置path属性为你保存文件的文件名
    $this->path = $this->getFile()->getClientOriginalName();

    // clean up the file property as you won't need it anymore
    // 清理你不需要的file属性
    $this->file = null;
}

 使用生命周期回调

生命周期回调是一种有限的技术，他有一些缺点。如果你想移除Document::getUploadRootDir()方法里的写死的编码__DIR__，最好的方法是开始使用Doctrine listeners。在哪里你将能够注入内核参数，如kernel.root_dir来建立绝对路径。

这种原理工作，他有一个缺陷：也就是说当entity持久化时会有什么问题呢？答：该文件已经转移到了它的最终位置，实体类下的path属性不能够正确的实体化。

（如果entity有持久化问题或者文件不能够移动，什么事情也没有发生）为了避免这些问题，你应该改变这种实现方式以便数据库操作和自动删除文件：

/**
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class Document
{
}

接下来,利用这些回调函数重构Document类:

use Symfony\Component\HttpFoundation\File\UploadedFile;

/**
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class Document
{
    private $temp;

    /**
     * Sets file.
     *
     * @param UploadedFile $file
     */
    public function setFile(UploadedFile $file = null)
    {
        $this->file = $file;
        // check if we have an old image path
        // 检查如果我们有一个旧的图片路径
        if (isset($this->path)) {
            // store the old name to delete after the update
            $this->temp = $this->path;
            $this->path = null;
        } else {
            $this->path = 'initial';
        }
    }

    /**
     * @ORM\PrePersist()
     * @ORM\PreUpdate()
     */
    public function preUpload()
    {
        if (null !== $this->getFile()) {
            // do whatever you want to generate a unique name
            // 去生成一个唯一的名称
            $filename = sha1(uniqid(mt_rand(), true));
            $this->path = $filename.'.'.$this->getFile()->guessExtension();
        }
    }

    /**
     * @ORM\PostPersist()
     * @ORM\PostUpdate()
     */
    public function upload()
    {
        if (null === $this->getFile()) {
            return;
        }

        // if there is an error when moving the file, an exception will
        // be automatically thrown by move(). This will properly prevent
        // the entity from being persisted to the database on error
        //当移动文件发生错误，一个异常move（）会自动抛出异常。
        //这将阻止实体持久化数据库发生错误。
        $this->getFile()->move($this->getUploadRootDir(), $this->path);

        // check if we have an old image
        if (isset($this->temp)) {
            // delete the old image
            unlink($this->getUploadRootDir().'/'.$this->temp);
            // clear the temp image path
            $this->temp = null;
        }
        $this->file = null;
    }

    /**
     * @ORM\PostRemove()
     */
    public function removeUpload()
    {
        $file = $this->getAbsolutePath();
        if ($file) {
            unlink($file);
        }
    }
}

 如果更改你的entity是由Doctrine event listener 或event subscriber处理，这个 preUpdate()回调函数必须通知Doctrine关于正在做的改变。有关preUpdate事件限制的完整参考请查看 http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/events.html#preupdate

现在这个类做了你需要的一切：他会在entity持久化之前生成一个唯一的文件名，持久化之后，移动文件，删除文件。

现在移动文件是entity自动完成，这个$document->upload()就应该从controller中移除了：

if ($form->isValid()) {
    $em = $this->getDoctrine()->getManager();

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

    return $this->redirect(...);
}

 这个@ORM\PrePersist()和@ORM\PostPersist()事件回调:一个是在entity持久化到数据库之前触发,一个是在entity持久化到数据库之后触发。另一方面， @ORM\PreUpdate() 和 @ORM\PostUpdate()事件回调时当实体更新时触发。

当改变entity字段后进行持久化操作时，PreUpdate和PostUpdate回调才会被触发。这意味着，默认情况下，你只改变了$file属性，这些事件不会被触发，因为这个属性它自己不会持久化到Doctrine。有一个解决方法，就是创建一个updated字段把它持久化到Doctrine，并当文件改变时手动调整它。

使用ID作为文件名

如果要使用ID作为文件名，实现略有不同，您需要保存path属性为文件扩展名,而不是实际的文件名:

use Symfony\Component\HttpFoundation\File\UploadedFile;

/**
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class Document
{
    private $temp;

    /**
     * Sets file.
     *
     * @param UploadedFile $file
     */
    public function setFile(UploadedFile $file = null)
    {
        $this->file = $file;
        // check if we have an old image path
        if (is_file($this->getAbsolutePath())) {
            // store the old name to delete after the update
            $this->temp = $this->getAbsolutePath();
        } else {
            $this->path = 'initial';
        }
    }

    /**
     * @ORM\PrePersist()
     * @ORM\PreUpdate()
     */
    public function preUpload()
    {
        if (null !== $this->getFile()) {
            $this->path = $this->getFile()->guessExtension();
        }
    }

    /**
     * @ORM\PostPersist()
     * @ORM\PostUpdate()
     */
    public function upload()
    {
        if (null === $this->getFile()) {
            return;
        }

        // check if we have an old image
        if (isset($this->temp)) {
            // delete the old image
            unlink($this->temp);
            // clear the temp image path
            $this->temp = null;
        }

        // you must throw an exception here if the file cannot be moved
        // so that the entity is not persisted to the database
        // which the UploadedFile move() method does
        $this->getFile()->move(
            $this->getUploadRootDir(),
            $this->id.'.'.$this->getFile()->guessExtension()
        );

        $this->setFile(null);
    }

    /**
     * @ORM\PreRemove()
     */
    public function storeFilenameForRemove()
    {
        $this->temp = $this->getAbsolutePath();
    }

    /**
     * @ORM\PostRemove()
     */
    public function removeUpload()
    {
        if (isset($this->temp)) {
            unlink($this->temp);
        }
    }

    public function getAbsolutePath()
    {
        return null === $this->path
            ? null
            : $this->getUploadRootDir().'/'.$this->id.'.'.$this->path;
    }
}

你会注意到，在这种情况下,你需要做一点工作,以删除该文件。在数据删除之前，你必须保存文件路径（因为它依赖于ID）。然后，一旦对象已经完全从数据库中删除，你就可以安全的删除文件（在数据删除之后）。

(Doctrine)如何处理Doctrine文件上传，首发于Symfony中文教程。