这篇文章讲述的内容是关于作用域的，作用域是有关服务容器的一个比较高级的主题。如果您曾经在创建一个服务的时候被提示有关于“作用域”的错误，那么这篇文章很值得您去阅读。如果您想要注入请求服务，一个简单的解决方案就是反向注入 request_stack 服务，并通过调用 [getCurrentRequest()](http://api.symfony.com/2.7/Symfony/Component/HttpFoundation/RequestStack.
Symfony 具有很多能触发您应用中的自定义行为的事件和钩子（hooks）。这些事件可以在 KernelEvents 类中查看并且是由 HttpKernel 组件引发。如果您想要挂钩到事件并添加您自己的自定义逻辑，您必须创建一种在这个事件中作为事件监听者的服务。在此条目中，您将创建一个作为异常监听器的服务，允许您修改您的应用程序异常的显示方式。
把一个对象序列化和反序列化成不同的格式（例如：JSON 或者 XML）是一个非常复杂的话题。在 Symfony 中有一个序列化程序组件 Serializer Component 可以给您提供一些工具来帮您解决上述问题。事实上，当您开始序列化和反序列化之前，您可以通过阅读序列化组件来了解并熟悉序列化，规范化子组件和编码器。激活序列化程序2.
每一种身份验证机制 (例如 HTTP 身份验证，登录表单等) 恰好使用一个提供程序，默认情况下将使用第一个声明的用户提供程序 。但是如果您想要通过配置文件制定一些用户来验证，其他的用户信息存在数据库里该怎么办？我们可能可以通过创建一个新的供应程序并把它和以前的提供程序串联在一起：YAML:# app/config/security.
对于每个传入的请求，Symfony 都检查每个 access_control 条目来找到一个匹配当前项的请求的 access_control。当它找到一个匹配的 access_control 项它便停止，只有第一个匹配的 access_control 用于强制执行访问。每个 access_control 拥有几个可以配置以下两个不同条件的选项：1. 传入的请求应匹配此访问控制项2. 一旦它匹配成功，应实施某种形式的访问限制1.
通常情况下，我们通过配置一个密码编码器使它能够适用于特定的类的所有实例来实现它可以被所有用户使用：YAML:# app/config/security.ymlsecurity: # ... encoders: Symfony\Component\Security\Core\User\User: sha512XML:<!-- app/config/security.xml --><?xml version="1.0" encoding="UTF-8"?><
当使用一个登录表单时，您应该确保可以抵御 CSRF (跨站点请求伪造)。安全组件已经对 CSRF 内置支持。在这篇文章中，您将学习如何在登录表单中使用它。登录 CSRF 并不是特别知名。如果您想要知道更多详细信息，请参阅锻造登录请求。配置 CSRF 保护首先，配置安全组件来让它可以使用 CSRF 保护。安全组件需要 CSRF 令牌提供程序。
默认情况下，安全组件将保留在名为 _security.main.target_path 的 session 变量中最后访问的 URL 信息(主要是在 security.yml 中定义的防火墙的名称)。成功登录后，将用户重定向到此路径，并帮助他们继续停留在访问过的最后一个已知网页。在某些情况下，这不是理想的。
某些 web 服务器，包括 Apache 已经提供大量的身份验证模块。这些模块一般设置一些环境变量来确定哪个用户正在访问您的应用程序。不确定的是，Symfony 支持大多数的身份验证机制。这些请求被称为预身份验证请求，因为当该用户访问您的程序的时候他已经通过了身份验证。X.509 客户端证书身份验证当使用客户端证书时，您的网络服务器会进行所有的身份验证过程。
创建一个人自定义的身份验证系统很难，本章将引导您完成这一进程。但根据您的需求，您可能可以通过一种更简单的， 或者通过集群包来解决这个问题:如何创建一个自定义表单的密码验证器如何使用 API 来进行用户身份验证如果要通过 OAuth 来使用第三方平台的服务，如谷歌、 Facebook 或者 Twitter 进行身份验证，那么请尝试使用 HWIOAuthBundle 集群包。
如今，我们常使用 API 去验证一个用户的身份 (例如开发一个 web 服务的时候)。该 API 密钥可以为每个请求提供服务，并且以查询字符串参数的形式或通过 HTTP 头部信息进行传递。API 密钥身份验证器我们应该通过预身份验证机制请求信息来对用户身份进行验证。SimplePreAuthenticatorInterface 接口能让您很容易的达到这个目的。
想象一下，如果您想要使您的网站只能在下午两点到四点之间才能被访问。在 Symfony 2.4 之前必须创建一个自定义的令牌、 工厂、 监听器和提供者才能实现。在本节中，您将学习如何在一个登录表单（即您的用户提交他们的用户名和密码的页面）中实现上述功能 。在 Symfony 2.6 之前，您必须使用密码编码器来验证用户的密码。密码身份验证器2.6 在 Symfony 2.
Symfony 的标准身份验证过程的一部分取决于"用户服务提供者"。当用户提交一个用户名和密码时，身份验证层便请求配置用户信息的程序返回一个用户对象来提供用户名。随后 Symfony 会检查此用户的密码是否正确，如果是正确的就会生成一个安全令牌，使用户在当前会话期间保持已经验证过的身份。当然不确定的是，Symfony 有一个 "in_memory" 和一个 "
在安全性一章中，您可以看到如何通过从服务容器请求 security.authorization_checker 并检查当前用户的角色来保护一个控制器：// ...http://symfony.com/doc/current/book/security.html#book-security-securing-controlleruse Symfony\Component\Security\Core\Exception\AccessDeniedException;public function helloAction($name){ $this->
使用表单登录来处理 Symfony 的验证是一件非常常见并且灵活的方法。几乎表单登录的每个方面都可以进行自定义，所有的默认配置都将在下一节中进行介绍。表单登录参考配置如果想要查看完整表单登录参考配置，请参考 [SecurityBundle 配置 ("安全")]( http://symfony.com/doc/current/reference/configuration/security.html)。如下列举了一些更有趣的解释选项。
在 Symfony 2.5 中， 添加了限定防火墙的多种可能的方法，你可以在“如何限定防火墙使其只允许通过指定请求”章节中查阅。
通过安全组件，你可以配置一个能通过某些请求选项的防火墙。大多数情况下，仅通过 URL 匹配就可实现要求了，但某些特殊情况下，可通过进一步限定防火墙，使其禁止不满足要求的请求通过，达到同样的目的。你可以使用任何这些限制,单独或混合在一起以得到您想要的防火墙配置。
您能在您的网站领域安全配置强制使用 HTTPS 协议。您可以强迫您的站点在安全配置中使用 HTTPS 协议。这是通过 access_control 规则使用 requires_channel 选项来完成的。例如，如果您想强制所有的 URL 以 /secure 开始来使用 HTTPS，那么你可以使用以下配置：YAML：access_control: - { path: ^/secure, roles: ROLE_ADMIN, requires_channel: https }XML:<
本章的目的是给出一个更深入的 ACL 系统的观点,并解释其背后的一些设计决策。设计概念Symfony 的对象实例的安全功能是基于一个访问控制列表的概念。每一个域对象实例都有自己的 ACL。ACL 实例有一个详细的列表,访问控制项(ACEs),用于访问决策。Symfony 的 ACL 系统集中在两个主要目标：为您的域对象提供一种方式来有效地检索大量的 ACLs / ACEs，并修改它们；
在复杂的申请中，你可能经常面临访问权限决策不仅仅取决于请求者本人（Token）还牵涉到了被申请的对象的问题。这也是 ACLs 系统被制作出来的原因所在。ACLs的替代选择使用 ACL 并不是细微之事，它的的确确对使用有简化功能。当然，它可能会滥杀无辜。如果你的判定逻辑只是被简单的代码来描述（比如检查这个博客是否被一个现在的使用者所拥有> ），那么就考虑使用 voters。
关注时代Java
