📄 acegi （version1_0_4）中文参考手册 [转载自 dxjsunday] - 懒散狂徒的专栏 - csdnblog.htm
字号:
要么返回403错误代码(如果principal通过了认证，只是缺少足够的权限，象上述第7步那样)，要么加载一个 AuthenticationEntryPoint
(如果principal还没有被认证，那么我们要从第3步开始)。 <BR><BR>AuthenticationEntryPoint
负责上述的第3步。如你所想，每个web应用都有一个默认的认证策略（象Acegi
Security中几乎所有的东西一样，它也是可配置的，不过我们现在还是还是从简单开始）。每个主流的认证系统都有它自己的
AuthenticationEntryPoint实现，负责执行第3步中描述的动作。 <BR><BR>当浏览器确定要发送你的认证信息（HTTP 表单或者HTTP
header），服务器上需要有什么东西来“收集”这些认证信息。现在我们在上述的第6步。在Acegi
Security中对从用户代理（通常是浏览器）收集认证信息有一个特定的名字，这个名字是“认证机制（authentication
mechanism）”。当认证信息从客户代理收集过来以后，一个“认证请求（Authentication
request）”对象被创建，并发送到AuthenticationProvider。 <BR><BR>Acegi
Security中认证的最后一环是一个AuthenticationProvider。非常简单，它的职责是取用一个认证请求 （Authentication
request）对象，并且判断它是否有效。这个provider要么抛出一个异常，要么返回一个组装完毕的Authentication对象。还记得我
们的好朋友UserDetails 和
UserDetailsService吧？如果没有，回到前一部分重新回忆一下。大部分的AuthenticationProviders都会要求
UserDetailsService提供一个UserDetails对象。如前所述，大部分的应用程序会提供自己的
UserDetailsService，尽管有些会使用Acegi Security提供的JDBC或者 in-memory实现。作为成品的UserDetails
对象，特别是其中的GrantedAuthority[]s，在构建完备的Authentication对象时会被使用。 <BR><BR>当认证机制
（authentication mechanism）取回组装完全的Authentication对象后，它将会相信请求是有效的，将Authentication放到
SecurityContextHolder中，并且将原始请求取回（上述第7步）。反之，AuthenticationProvider则拒绝请求，认
证机制（authentication mechanism）会请求用户重试（上述第2步）。 <BR><BR>在讲述典型的认证流程的同时，有个好消 息是Acegi
Security不关心你是如何把Authentication放到SecurityContextHolder内的。唯一关键的是在
AbstractSecurityInterceptor授权一个请求之前，在SecurityContextHolder中包含一个代表了
principal的Authentication。 <BR><BR>你可以（很多用户确实）实现自己的过滤器（filter）或者MVC控制器
（controller）来提供和不是基于Acegi Security的认证系统交互。例如，你可能使用使用容器管理认证（Container Managed
Authentication），从ThreadLocal
或者JNDI中获取当前用户信息，使得它有效。或者，你工作的公司有一个遗留的私有认证系统，而它是公司“标准”，你对它无能为力。在这种情况之下也是非
常容易让Acegi Security运作起来，提供认证能力。你所需要做的是写一个过滤器（或等价物）从某处读取第三方用户信息，构建一个Acegi
Security式的Authentication对象，把它放到SecurityContextHolder中。这非常容易做，也是一种广泛支持的集成 方式。
<BR>acegi参考手册(v1.0.4)[译]-第二章 技术概览[下] <BR>2.4. 安全对象 <BR>如果你熟悉AOP，你会知
道有很多种advice可用：before, after, throws 和 around。around
advice非常有用，因为它能够选择是否选择是否执行一个方法调用，是否修改返回值，以及是否抛出异常。Acegi
Security对方法调用和web请求都提供around advice。我们使用AOP联盟实现对方法调用的around
advice，对于web请求的around advice则是使用标准的过滤器（Filter）。 <BR><BR>对于那些不熟悉AOP的人来说，
关键是要理解Acegi
Security能够帮助你保护方法调用以及web请求。大多数人对保护他们服务层的方法调用感兴趣。这是因为在当前的J2EE应用中，服务层包含了大多
数的业务逻辑（声明，作者不赞成这种设计，反而支持正确封装的领域模型以及DTO，assembly, facade 以及 transparent
persistence patterns，而不是当前主流的贫血模型，我们将在这里讨论）。如果你需要保护service层的方法调用，使用标准的Spring
AOP平台（或者被成为AOP 联盟（AOP Alliance））就足够了。如果你需要直接对领域模型进行保护，那么可以考虑使用AspectJ。 <BR><BR>你
可以选择对使用AspectJ 或者AOP联盟（AOP
Alliance）对方法进行授权，或者你可以选择使用过滤器（filter）来对web请求进行授权。你将0个，1个，2个或者3个这些方法一起使用。
主流的用法是执行一些web请求授权，以及在服务层使用AOP联盟（AOP Alliance）对一些方法调用授权。 <BR><BR>Acegi
Security使用“安全对象”（secure object）这个词来指任何能够将安全应用于其上的对象。每个Acegi
Security支持的安全对象都有自己的类，它是AbstractSecurityInterceptor的子类。重要的一点是，如果一个
principal通过认证，当AbstractSecurityInterceptor执行的时候，SecurityContextHolder中要包
含一个有效的Authentication。 <BR><BR>AbstractSecurityInterceptor提供一个固定的工作流程来处理
安全对象请求。这个工作流程包括查找和当前请求相关联的“配置属性（configuration attributes）”。配置属性（configuration
attributes）可以被认为是对被AbstractSecurityInterceptor使用的类有特殊含义的字符串。他们通常针对
AbstractSecurityInterceptor使用XML进行配置。反正，AbstractSecurityInterceptor会询问
AccessDecisionManager “这是配置属性（configuration attributes），这是当前的认证对象（Authentication
object），这是当前请求的详细信息－那么这个特定的principal可以执行这个特定的操作吗？”。 <BR><BR>假如
AccessDecisionManager判定允许这个请求，那么AbstractSecurityInterceptor一般来说就继续执行请求。虽
然这样，用户在少数情况之下可能需要替换SecurityContext中的Authentication，可以通过
AccessDecisionManager调用一个RunAsManager来实现。在某些不常见的情形下这将非常有用，例如服务层的方法需要用另一种
标识（身份）来调用远程系统。这可能有所帮助，因为Acegi Security自动在不同的服务器之间传播安全标识（假设你正确配置了RMI或者HttpInvoker
remoting protocol client）。 <BR><BR>随着安全对象处理和返回－意味着方法调用完毕或者过滤器链（filter
chain）处理完毕－AbstractSecurityInterceptor有最后的机会来处理调用。这时，
AbstractSecurityInterceptor可能会修改返回的对象。我们可能要这样做，因为授权判断不能在安全对象调用途中执行。由于高度的
可插拔性，如果需要AfterInvocationManager将控制权交给AfterInvocationManager来实际修改对象。这个类甚至
可以彻底替换对象，或者抛出异常，或者根本不修改它。
<BR><BR>因为是AbstractSecurityInterceptor中心模版类，看起来第一副插图该献给它。（译注：原手册里的图画的太丑陋了，我用jude重新画了一遍）
<BR><!--[if gte vml 1]><v:shapetype id="_x0000_t75"
coordsize="21600,21600" o:spt="75" o:preferrelative="t"
path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"> <v:stroke
joinstyle="miter" /> <v:formulas> <v:f eqn="if lineDrawn
pixelLineWidth 0" /> <v:f eqn="sum @0 1 0" /> <v:f eqn="sum 0 0 @1"
/> <v:f eqn="prod @2 1 2" /> <v:f eqn="prod @3 21600 pixelWidth"
/> <v:f eqn="prod @3 21600 pixelHeight" /> <v:f eqn="sum @0 0 1"
/> <v:f eqn="prod @6 1 2" /> <v:f eqn="prod @7 21600 pixelWidth"
/> <v:f eqn="sum @8 21600 0" /> <v:f eqn="prod @7 21600 pixelHeight"
/> <v:f eqn="sum @10 21600 0" /> </v:formulas> <v:path
o:extrusionok="f" gradientshapeok="t" o:connecttype="rect" /> <o:lock
v:ext="edit" aspectratio="t" /> </v:shapetype><v:shape
id="_x0000_i1025" type="#_x0000_t75" style='width:423pt; height:270.75pt'>
<v:imagedata src="file:///C:\WINDOWS\TEMP\msohtml1\01\clip_image001.jpg"
o:title="ch2-1" /> </v:shape><![endif]--><!--[if
!vml]--><!--[endif]--> <BR><BR>图1 关键“安全对象”模型 <BR><BR>只有那些希望实现全
新的对请求进行截取截取和授权方式的开发者才需要直接使用安全对象。例如，可能构建一个新的安全对象安全调用一个消息系统。任何需要安全并且能够提供一种
截取调用的方式(例如AOP around advice
semantics)的东西都可以成为安全对象。虽然如此，大部分的Spring应用都会只是透明应用当前支持的三种安全对象类型（AOP Alliance
MethodInvocation, AspectJ JoinPoint 和 web request FilterInterceptor）。
<BR><BR>2.5. 结论 <BR>恭喜！你已经获取了Acegi
Security足够的概括性的图景来开始着手你的项目。我们探究了共享组件，认证过程，以及对“安全对象”的通用授权概念。手册中的余下部分你可能用到也可能用不到，可以按照任意顺序阅读。
<BR>acegi参考手册(v1.0.4)[译]-第三章 协助系统 <BR>第三章. 协助系统 <BR>本章介绍一些Acegi
Security使用的附加和协助系统。那些和安全无关，但是包含在Acegi Security项目中的部分，将会在本章中讨论 <BR>3.1. 本地化
<BR>Acegi Security支持对终端客户可能会看到的异常信息进行本地化。如果你的应用是为英文用户设计的，那么你什么都不用做，因为Acegi
Security的所有消息默认都是英文的。如果你要支持其他区域用户，那么本节包含了你所需要了解的所有东西。
<BR>包括认证失败或者访问被拒绝（授权失败）的所有异常消息都可以被本地化。提供给开发者或者系统部署人员的异常或者日志信息(包括错误的属性、接口不符、构造器错误、debug级日志)没有被本地化，它们硬编码在Acegi
Security的代码中。 <BR>在acegi -security-xx.jar（译注：xx代表版本号）的org.acegisecurity包中包含了一个
messages.properties文件。这个文件会被你的application context引用，因为Acegi
Security实现了Spring的MessageSourceAware接口，它期待在application context启动的时候注入一个message
resolver。通常你所需要做的是在你的application context中注册一个引用这个消息的bean，如下所示： <BR>xml 代码
<BR><BR>1. <bean id="messageSource"
class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
<BR>2. <property
name="basename"><value>org/acegisecurity/messages<!--</span-->value><!--</span-->property>
<BR>3. <!--</span-->bean>
<BR><BR>messages.properties是按照资源包标准命名的，它代表了Acegi
Securtiy支持的默认语言。文件默认是英文的。如果你不注册一个消息源，Acegi Security仍然可以正常工作，它会用回硬编码的英文消息。 <BR>如
果你想定制messages.properties文件，或者支持其他语言，那么你应该copy这个文件，然后重命名，并在上述的bean定义中
注册。因为文件中的key并不多，因此本地化花不了多少工夫。如果你针对消息文件进行了本地化，那么请和社区分享，你可以添加一个JIRA任务，将你正确
命名的messages.properties本地化文件作为附件添加。 <BR>为了完善关于本地化的讨论需要知道Spring的 ThreadLocal
org.springframework.context.i18n.LocaleContextHolder。你应该为每个用户设置代表他区域的
LocaleContextHolder。Acegi
Security会尝试从这个ThreadLocal中获取的Locale来从消息源中获取消息。请参考Spring的文档以获取更多使用
LocaleContextHolder和能够帮你自动设置它的辅助类(例如 <BR>AcceptHeaderLocaleResolver,
CookieLocaleResolver, FixedLocaleResolver, SessionLocaleResolver 等)的详细信息。
<BR>3.2. Filters <BR>正如你在整个手册中看到的那样，Acegi
Security使用很多filter。你可以使用FilterToBeanProxy或者FilterChainProxy来确定这些是怎样加入到你的web应用中的，下面我们来看看。
<BR>大部分filter使用FilterToBeanProxy来配置。例如下面web.xml中配置所示： <BR>xml 代码 <BR><BR>1.
<filter> <BR>2. <filter-name>Acegi HTTP Request Security
Filter</filter-name> <BR>3.
<filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
<BR>4. <init-param> <BR>5.
<param-name>targetClass</param-name> <BR>6.
<param-value>org.acegisecurity.ClassThatImplementsFilter</param-value>
<BR>7. </init-param> <BR>8. </filter> <BR><BR><BR>注
意在web.xml中的filter实际上是一个FilterToBeanProxy，而不是真正实现filter逻辑的filter。
FilterToBeanProxy所作的是代理Filter的方法到一个从Spring的application context
获取的bean。这使得这个bean可以享受Spring application
context的生命周期支持以及配置灵活性。这个bean必须实现javax.servlet.Filter。 <BR>FilterToBeanProxy
只需要一个简单的初始化参数，targetClass或者targetBean。targetClass会定位 application
context中指定的类的第一个对象，而FilterToBeanProxy按照bean的名字定位对象。象标准的Spring
web应用一样，FilterToBeanProxy使用
WebApplicationContextUtils.getWebApplicationContext(ServletContext)来访问
application context，所以你应该在web.xml中配置一个ContextLoaderListener。 <BR><BR>在IoC
容器而不是servlet容器中部署Filter会有一个生命周期的问题。特别是，哪个容器应该负责调用Filter的"startup" 和
"shutdown"方法？注意到Filter的初始化和析构顺序随servlet容器不同而不同，如果一个Filter依赖于由另一个更早初始化的
Filter的配置，这样就会出现问题。另一方面，Spring IoC具备更加完善的生命周期/IoC接口（例如InitializingBean,
DisposableBean, BeanNameAware,
ApplicationContextAware以及其他许多）以及一个容易理解的接口契约（interface
contract），可预见的方法调用顺序，自动装配支持，以及可以避免实现Spring接口的选项（例如Spring XML中的destroy-method
属性）。因此，我们推荐尽可能使用Spring生命周期服务而不是servlet容器生命周期服务。FilterToBeanProxy默认不会将
init(FilterConfig) 和
destroy()方法委派到被代理的bean。如果你需要这些调用被委派，那么将lifecycle初始化参数设置为servlet-
container-managed。 <BR>我们强烈推荐你使用FilterChainProxy而不是FilterToBeanProxy。虽然
FilterToBeanProxy是一个非 常有用的类FilterToBeanProxy，问题是当web.xml中filter变多时， 和
项就会太多而变得臃肿不堪。为了解决这个问题，Acegi
Security提供一个FilterChainProxy类。它在FilterToBeanProxy中被装配（正如上面例子中所示），但目标类 （target
class）是org.acegisecurity.util.FilterChainProxy。这样过滤器链（filter
chain）可以在application context中按照如下代码配置： <BR>xml 代码 <BR><BR>1. <bean
id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy"> <BR>2.
<property name="filterInvocationDefinitionSource"> <BR>3. <value>
<BR>4. CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON <BR>5. PATTERN_TYPE_APACHE_ANT
<BR>6.
/webServices/*=httpSessionContextIntegrationFilterWithASCFalse,basicProcessingFilter,exceptionTranslationFilter,
<BR>7.
/*=httpSessionContextIntegrationFilterWithASCTrue,authenticationProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor
<BR>8. <!--</span-->value> <BR>9. <!--</span-->property>
<BR>10. <!--</span-->bean> <BR><BR>你
可能注意到FilterSecurityInterceptor定义方式的相似之处。同时支持正则表达式和Ant
Paths格式，越对应的URI越早出现。在运行时，FilterChainProxy会定位符合当前的web请求的第一个URI模式。每个对应的配置属
性代表了在application
context中定义的一个bean的名字。接着fiter会按照它们被指定的顺序，按照FilterChain的标准行为模式被调用(如果一个
Filter决定停止处理，它可以不在chain中执行)。 <BR>如你所见，FilterChainProxy需要为不同的请求模式重复配置
filter的名字（在上面的例子中，, exceptionTranslationFilter 和 filterSecurityInterceptor
是重复的）。这样的设计是为了让FilterChainProxy能够为不同的URI配置不同的filter调用顺序，同时也提高了表达力（针对正则表达 式、Ant
Paths、以及任何FilterInvocationDefinitionSource的特定实现）和清晰度，可以知道是哪个filter应该被调用。⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -