ACEGI安全框架应用指南

45/45ACEGＩ安全框架应用指南级别：中级何平系统架构师,独立顾问，培训讲师.2005年12月26日文章来源于一次acegｉ的项目应用。因为业务需要与acegi框架缺省的应用方式有一定的区别，故在实际应用过程中尝试了对aｃegi的一定量的改造工作,从而具有一定的研究和学习价值。文章中关于Acegi的介绍收入了其他文章中的内容，已在参教资料中列出资料来源。内容大纲:

认识Ａcegi安全框架

安装并运行Acｅgi自带的范例

改造Aｃｅgi框架满足我们的业务要求

具体内容：

认识Acegi安全框架Acegi安全系统，是一个用于SpringFrameｗork的安全框架，能够和目前流行的Web容器无缝集成.它使用了Ｓｐriｎg的方式提供了安全和认证安全服务，包括使用ＢeanContexｔ,拦截器和面向接口的编程方式.因此,Ａcegｉ安全系统能够轻松地适用于复杂的安全需求。安全涉及到两个不同的概念,认证和授权。前者是关于确认用户是否确实是他们所宣称的身份。授权则是关于确认用户是否有允许执行一个特定的操作。

在Aｃｅgi安全系统中，需要被认证的用户，系统或代理称为＂Ｐrｉncipal＂。Ａcegi安全系统和其他的安全系统不同,它并没有角色和用户组的概念

关键组件Acegi安全系统包含以下七个关键的功能组件:lAuｔhentiｃatiｏn对象,包含了Ｐriｎcipal,Ｃｒedentｉaｌ和Ｐrｉｎcipal的授权信息.同时还可以包含关于发起认证请求的客户的其他信息,如IP地址。

2CoｎteｘｔHｏlｄer对象，使用ＴhreaｄLocaｌ储存Authenticatioｎ对象的地方。

3AuthenticatｉｏnManager，用于认证ConｔextHolｄeｒ中的Autｈｅnticａｔion对象。

4AccｅsｓDeｃissionMａｎageｒ，用于授权一个特定的操作。

５RunAｓＭａnａger，当执行特定的操作时，用于选择性地替换Aｕｔheｎｔicaｔioｎ对象.

６ＳecurｅＯbｊｅｃt拦截器，用于协调ＡuｔhenｔiｃａtｉonManａger,AｃcessＤｅcｉｓｓioｎManager，RunＡsManageｒ和特定操作的执行.７ObjectDｅfｉniｔｉonSource,包含了特定操作的授权定义.这七个关键的功能组件的关系如下图所示(图中灰色部分是关键组件)：

安全管理对象Aｃegi安全系统目前支持两类安全管理对象.

第一类的安全管理对象管理AOPＡｌliancｅ的MetｈodInvｏcａtioｎ，开发人员可以用它来保护Sｐring容器中的业务对象。为了使Sｐring管理的Bean可以作为MethｏdInvocatｉon来使用，Bｅａn可以通过ＰroxyＦaｃｔoryＢeａn和BeanNameAｕtoＰｒｏxyCreator来管理,就像在Spｒiｎｇ的事务管理一样使用.

第二类是FiltｅrIｎvｏcation。它用过滤器（Ｆｉｌteｒ)来创建,并简单地包装了ＨTＴP的ServｌetRequeｓt，SeｒｖletResponｓe和FｉlterＣhａin。FiｌｔerInvoｃatｉon可以用来保护ＨＴTP资源。通常，开发人员并不需要了解它的工作机制，因为他们只需要将Filｔer加入weｂ.ｘml,Acegi安全系统就可以工作了.

安全配置参数每个安全管理对象都可以描述数量不限的各种安全认证请求。例如，MｅtｈｏdIｎvoｃａtion对象可以描述带有任意参数的任意方法的调用，而FiｌｔeｒInｖoｃation可以描述任意的HＴTPURL。

Acｅgi安全系统需要记录应用于每个认证请求的安全配置参数。例如，对于BankManager.getBalanｃe(intaccｏuntNumber）方法和BａnkMaｎager．appｒoｖeＬoａn(ｉnｔａppｌicationNｕｍber）方法,它们需要的认证请求的安全配置很不相同.

为了保存不同的认证请求的安全配置，需要使用配置参数。从实现的视角来看,配置参数使用ConfiｇＡttribuｔｅ接口来表示。Acegi安全系统提供了ConfigAttrｉbute接口的一个实现，SeｃｕrityCｏｎfig,它把配置参数保存为一个字符串。

ConfigAtｔribuｔｅＤｅfｉnｉtion类是CｏｎfigAttrｉbuｔe对象的一个简单的容器，它保存了和特定请求相关的CｏｎfigＡttributｅ的集合。

当安全拦截器收到一个安全认证请求时，需要决定应用哪一个配置参数。换句话说，它需要找出应用于这个请求的CoｎfigＡttriｂuteDｅfinition对象。这个查找的过程是由OｂjｅｃtDeｆinitionＳource接口来处理的。这个接口的主要方法是ｐubｌicＣｏｎｆigAttributeDefiｎitiｏngetAttｒibuｔes（Objectobjeｃt),其中Obｊｅｃt参数是一个安全管理对象。因为安全管理对象包含有认证请求的详细信息,所以ＯbｊectＤｅｆinitioｎSoｕrce接口的实现类可以从中获得所需的详细信息，以查找相关的ConfigAtｔributeDeｆｉniton对象。

Acegｉ如何工作为了说明Acegi安全系统如何工作,我们设想一个使用Ａcegｉ的例子。通常，一个安全系统需要发挥作用，它必须完成以下的工作：

l首先，系统从客户端请求中获得Prinｃiｐaｌ和Credeｎtiａｌ；

２然后系统认证Principal和Ｃredｅntial信息；

3如果认证通过，系统取出Priｎcｉpａl的授权信息;

4接下来，客户端发起操作请求；

5系统根据预先配置的参数检查Priｎcipal对于该操作的授权;6如果授权检查通过则执行操作,否则拒绝。

那么,Acegi安全系统是如何完成这些工作的呢？首先，我们来看看Aｃegi安全系统的认证和授权的相关类图：

图中绿色部分是安全拦截器的抽象基类，它包含有两个管理类,AuthenticaｔｉonManａgｅr和AcｃｅｓsDecisｉｏｎＭａnａgeｒ,如图中灰色部分.ＡuｔhenｔicationＭanaｇer用于认证ＣoｎtextHoldeｒ中的Autｈｅｎｔiｃatｉon对象（包含了Pｒincｉpal,Ｃredenｔial和Ｐrｉｎｃipaｌ的授权信息）；AｃｃｅssDeciｓsioｎManaｇer则用于授权一个特定的操作。下面来看一个MeｔhodSｅｃuｒiｔyInteｒｃｅptor的例子:<beａnid="bａnkManagerＳecurity”

ｃｌasｓ＝”ｎｅｔ。ｓf．acegisecurity。ｉｎｔerｃｅｐt．mｅｔhod.ＭｅtｈｏdSｅcuｒｉｔyIntercｅptor”〉

〈prｏpｅrtynaｍe="validａteCoｎfigAｔtｒibutｅs">

〈vａlue＞trｕe〈/valｕe＞

〈/ｐｒoperｔy〉

〈ｐropeｒｔｙｎame＝”aｕｔhentｉｃatiｏnManａger">

<refbean="authenticationＭaｎａger"/〉

</propｅrtｙ〉

〈pｒoｐeｒtｙnamｅ=＂aｃceｓｓDeciｓｉonManａｇｅr"＞

<reｆbｅaｎ＝"accessDecｉsiｏnMaｎａgeｒ＂/>

<／pｒｏperｔy>

〈prｏｐerｔyname=＂ｏbjｅｃtＤｅfiｎitiｏnSoｕrce">

〈vａluｅ＞

nｅt。sf.acｅgiseｃｕritｙ.context。BanｋManager．delete*=

ＲOＬE＿SUPEＲVＩSＯR,RUN_AＳ_SＥRVERnｅt。sｆ。aceｇisecｕriｔy。cｏntext。BaｎkManａgｅｒ.getBalance=

ＲOLE_TELLEＲ，ＲOＬE＿ＳUPERＶＩＳOR,ＢＡNＫSECＵRＩTＹ＿CUＳTＯMEＲ,RUN_

＜/value>

</propeｒty>

＜/ｂeaｎ>上面的配置文件中，ＭethodSecｕrityＩntｅｒceptｏｒ是AｂstraｃtＳecurityIｎterｃｅpｔｏr的一个实现类。它包含了两个管理器,aｕthｅnticaｔionManａger和ａｃcesｓDｅcisｉonMaｎageｒ。这两者的配置如下:

〈ｂeａniｄ="authentiｃatiｏｎDao"clａss=＂ｎet.sｆ．aｃegisecuｒity.prｏvｉｄers。dao．ｊdbc.JdbcＤaoImpl”>

<proｐｅｒtyｎamｅ=＂ｄataSoｕrce＂>〈reｆbean＝”dａｔaSouｒｃe”／>〈/pｒopertｙ>

</beａn〉

＜beanid="daoＡuｔhentiｃationPｒoｖiｄｅr”

class＝"nｅt.sf．ａｃegiseｃuｒity.prｏvidｅrｓ.dao．DaoAuthentｉcatｉonPｒovider">

<propertyｎame＝"autｈentｉcatｉonDao”><ｒeｆbｅan=”authentｉcaｔｉｏnDao"／〉</properｔy>

＜/ｂｅａn〉

＜bｅａnid=”auｔｈｅｎticatiｏnManager"clａsｓ＝"nｅt.sf．aｃegｉｓecｕrｉtｙ．providers.ＰroviderManａgeｒ”＞

＜pｒopertyname＝"pｒｏvｉders”>

＜list〉<ｒefbean="daoAuｔhenticationProviｄｅr"/><／lｉsｔ>

〈／prｏｐeｒty〉

<／ｂean>

〈beanid＝”rｏleVoｔeｒ"clａsｓ=”net．sf.acegisecuｒitｙ．vote．RｏlｅVoteｒ”/>

〈beａniｄ=＂ａccessDecisionManａgｅr＂clasｓ=”net．ｓｆ．ａcｅｇｉsecuritｙ.vote．AffirmativeＢased＂〉

＜pｒoｐerｔynamｅ=＂alｌｏｗIｆAｌlAbstainDeｃｉｓionｓ"〉〈ｖalue〉false＜/value></ｐroｐeｒｔy＞

〈ｐｒopertyｎame=＂ｄｅcｉsｉonＶoterｓ＂>

<liｓt〉＜refbeaｎ="ｒoleVoter＂/＞＜/lｉsｔ＞

</ｐroperty〉

＜／ｂean>

准备工作做好了,现在我们来看看Acegｉ安全系统是如何实现认证和授权机制的。以使用HTTPＢASＩC认证的应用为例子,它包括下面的步骤：1。

用户登录系统,Acｅgi从aｃeｇisｅｃｕrｉｔｙ．ui子系统的安全拦截器（如BasicＰroｃessinｇＦiｌter）中得到用户的登录信息(包括Principａl和Cｒedeｎtial)并放入Ａuｔheｎtication对象,并保存在ＣontextHolｄｅr对象中；

2.安全拦截器将Ａuthenticａtion对象交给ＡｕtｈenticationＭａｎager进行身份认证，如果认证通过，返回带有Principal授权信息的Authenticａtiｏｎ对象。此时ContextＨolder对象的Ａuthenｔicaｔiｏn对象已拥有Ｐrinｃipal的详细信息;

3.用户登录成功后，继续进行业务操作；4．安全拦截器（bａｎkMａnagｅrSecurity）收到客户端操作请求后，将操作请求的数据包装成安全管理对象(ＦiｌteｒＩnvocatiｏn或MｅtｈoｄInvocａtion对象)；5.然后，从配置文件（ObｊeｃｔDｅfiniｔioｎSoｕrce)中读出相关的安全配置参数ＣonfｉgAttrｉbuｔｅＤefinｉtiｏｎ；6。接着,安全拦截器取出ContｅxtHｏlｄer中的Autｈenｔicatiｏn对象，把它传递给AuthentｉcationMａnａｇer进行身份认证,并用返回值更新CｏnｔextHoｌdｅr的Aｕｔhｅntｉｃａｔion对象；７。将Autｈenｔicａtｉｏn对象,CｏnfigAｔtributｅDefinition对象和安全管理对象(ｓecureObject)交给ＡccesｓDecisionMａnageｒ,检查Princｉpaｌ的操作授权;

８。如果授权检查通过则执行客户端请求的操作，否则拒绝；

AcｃessDecisionVoteｒ注意上节的ａccessDｅciｓionMａnａｇer是一个AｆfirmatｉvｅＢased类,它对于用户授权的投票策略,只要通过其中的一个授权投票检查，即可通过;它的alloｗＩfAllAbstainＤecｉｓioｎｓ属性值是faｌse,意思是如果所有的授权投票是都是弃权，则通不过授权检查。Acegｉ安全系统包括了几个基于投票策略的AcｃｅssDｅcisiｏnMaｎａｇer，上节的ＲｏleVoｔer就是其中的一个投票策略实现，它是ＡccessＤeciｓｉonVｏter的一个子类。AccｅｓsDecｉｓiｏnＶoteｒ的具体实现类通过投票来进行授权决策，AcceｓｓDecisiｏnManager则根据投票结果来决定是通过授权检查,还是抛出AcｃessDenieｄEｘceｐtiｏn例外。

AｃｃessDecisionVotｅｒ接口共有三个方法：publicintｖote（Authｅnticationａｕthｅｎticａtｉon，Obｊｅctobjeｃt，CoｎfｉgAttributｅDｅfｉnitｉｏnｃｏｎfig);puｂｌicｂｏｏleanｓｕppｏrts（ConfｉｇAｔtributeａtｔribute）；ｐubｌｉcboｏｌeansuｐports(Ｃlassclａzz）;其中的vｏtｅ方法返回iｎｔ返回值,它们是AｃcｅｓsDｅcisionVoｔｅr的三个静态成员属性：ACCESＳ_ＡBSＴAIN，，ACCESＳ_ＤENIED和AＣCESＳ＿GRＡNＴEＤ,它们分别是弃权，否决和赞成。Acegｉ安全系统中，使用投票策略的AcceｓsDecisｉonMaｎagｅr共有三个具体实现类：AｆｆirｍativｅBａsｅd、CｏnsｅｎsusＢaseｄ和UnanｉmoｕsBased.它们的投票策略是,ＡfｆirmａｔiveＢaｓed类只需有一个投票赞成即可通过；ConsenｓusBaseｄ类需要大多数投票赞成即可通过;而UnanimousBａsed类需要所有的投票赞成才能通过。RolｅＶoter类是一个Aceｇi安全系统AccｅssDｅcisｉoｎVoter接口的实现.如果ConfiｇAｔtｒibute以ROLE_开头,RoleＶoｔｅr则进行投票.如果ＧrａntedAｕthorｉｔy的gｅtAuｔｏritｙ方法的Ｓtring返回值匹配一个或多个以RＯLＥ_开头的CｏnfigAtｔrｉｂuｔｅ，则投票通过，否则不通过。如果没有以RＯLＥ＿开头的ConｆigAttriｂute，RｏｌｅVoter则弃权。

小结到这里,我想各位对于Aｃegi安全框架的实现原理和运行机制已经有了较清楚的认识.下一步我们就理论联系实践来感觉一下Aceｇｉ给我们带来乐趣。

安装并运行acegi自带的范例为了让大家对aceｇi有一个感性的认识，下面我们一起来安装Acｅgi自带的demo，并运行它，亲身感觉Acｅgi都为我们带来了些什么。

需要的软件Ａcegi0。８３版本注意，目前Ａｃｅｇi的发布版本还不是很稳定,如果大家要运行我后面提供的范列,最好是下载这个版本的。下载地址:

因为我们还需求分析它的源码，所以最好也下之

Ｔomcat５.5下载地址：

J2SE5。0下载地址:

安装范例1.

安装tomcat到合适的位置２．

解压aceｇi—security—0．８.3.ziｐ,目录展开如下：

图中选中的文件就是我们将安装的deｍｏ.

3。

将acegｉ—secｕriｔｙ-sａmｐｌe-contactｓ—filteｒ.wａr复制到tomｃａｔ/ｗeｂapｐs目录下４。

启动tomcat5.

通过地址：访问dｅmo界面如下：6.

打开上面的页面后，大家就可以亲身去体验Acｅgi为我们来了什么.

提示其实只要好好研究一下这个ｄeｍｏ中对于Aceｇi的用法，基本上就可以掌握Aceｇｉ了.一起加油吧.

改造Aｃegi框架满足我们的业务要求

我们的Acegi的范例在前面介绍Ａｃｅｇi时，我们举例说明了Acegi是如何做到对业务对象的访问控制的。在更多的时候，对于Ｗeb应用程序还要控制页面的访问。而我们的业务要求就是这样的简单，根据不同的角色决定它能访问哪些页面和哪些对象的哪些方法.目前暂时不考虑具体角色的具体权限指派,关于这部分内容大家可以通过研究ｄemo获得相应的知识。因为是举例说明Acｅgi的用法，现假设我们的ｗeb工程名为mｙaｃeｇｉ，其目录结构如下：

其中的securｅ目录下的文件就是我们希望受控制的页面.

ｓrc目录是我们的jａva源程序。

acegiｌogiｎ.ｊｓp是我们的登录界面.

ｌogoff．jsp是我们的登出页面。

teｓt.jｓp页面中有我们对受控业务对象的受控方法的访问举例。

WEB-INF目录下的目录结构如下：

ｃlａsses和lｉｂ目录就不再解释了

applｉｃationCoｎtexｔ－common-buｓｉness．ｘml配置了例子中要使用的数据源

applicatioｎＣｏnｔeｘt-aｃegi-seｃurｉty．xmｌ配置了例子中关于安全方面的内容

apｐliｃａtｉｏnContext—common-authorizａtion。ｘｍl配置了例子中关于授权方面的内容

web.xｍｌ当然就是整个web应用的配置了。我们在这里先详细说明一下ｗeb．xml文件，其它的配置文件的内容将在后面的改造过程中不断深入web．ｘｍl文件内容如下：

〈?xｍlvｅrｓiｏn＝＂１．０＂eｎcoｄｉnｇ=”UＴＦ-8”?〉＜！DOCTYPEwｅb－apｐPUBLＩC’－／/SunＭicｒoｓystｅｍs，Ｉnc.//DTDWeｂApplicaｔion2.３／/ＥN＇＇’〉

<web-app>

〈disｐlay-name>mｙaｃｅｇiexａmple〈/display—ｎａme＞

〈context-paｒaｍ＞

＜paｒam—namｅ>ｃonteｘtConfiｇLoｃａtion〈/parａｍ—namｅ>

＜ｐaｒaｍ—valuｅ＞

／WＥB—INＦ/ａｐplicaｔionConｔext—aｃegｉ—ｓeｃurity。xml

/WEB—INF/applicatiｏnContｅxt—cｏmmon—business。ｘｍl

／WＥB—ＩNF/appｌｉcatiｏnContext—ｃommon—auｔｈorizatioｎ．xml

〈/param－ｖaluｅ>

＜/cｏnｔeｘt-param＞

〈fｉlter＞

＜fiｌter—nａme〉AcｅｇｉＦiｌterChainProxy＜/fｉltｅｒ－naｍe＞

<ｆilter－class〉

ｎｅt.sf.ａcｅgｉsecｕrity。utｉl.ＦｉlterToＢeanProxｙ

</fiｌtｅr-cｌass〉

〈iｎｉt－param>

<paｒam-ｎaｍe＞ｔargｅtClaｓｓ</pａraｍ-naｍe＞

〈param-value>

neｔ。sｆ．ａｃegisecｕrity。ｕtil。ＦilterＣｈainProxy

〈/paraｍ—value＞

<／ｉnit—ｐａｒaｍ〉

</filteｒ〉

＜filｔer－mapping＞

<ｆilter-ｎame>ＡcegiFｉlteｒＣｈａinＰrｏxy〈/filｔｅr—name＞

＜ｕrl-ｐaｔtｅrn〉／*</uｒl-paｔteｒn＞

</fiｌter－ｍａpｐinｇ〉

＜lisｔｅner>

＜ｌistｅnｅr-ｃlaｓｓ＞

oｒg.ｓｐｒingfraｍework．web.coｎtｅxｔ。CoｎteｘtLoａｄｅrListeneｒ

<／lｉsｔener-class＞

〈/lｉstｅner＞

〈lisｔeｎｅr＞

＜ｌisｔeｎer－cｌaｓs>

net．sｆ。ａｃegisecurity.ui．sｅssｉｏn.HttpＳeｓsionEｖeｎｔPｕｂlisher

</listｅner－ｃlass〉

〈/lisｔeｎer〉

〈ｗｅlcome-〉

<welcome—</welcome-ｆile〉

</weｌcomｅ—〉

＜taglib>

<taｇlib—uri>/spriｎg＜/taｇlib－ｕri＞

〈ｔaglib-loｃａｔioｎ>/WEB—INＦ/sprｉnｇ.tld</tａgliｂ-location＞

</ｔａｇlib＞

＜/web－apｐ＞

在上面的配置中,我只说明与Aｃeｇｉ有直接关系的部分1。

定义了一个应用程序域的变量coｎｔeｘtＣｏnfigＬocation

〈cｏｎtexｔ—ｐaram>

<ｐaram－name>ｃｏｎteｘtＣonｆiｇLocatiｏn〈／param—ｎａme>

〈parａm-value〉

/WEB—INF/appliｃationＣontexｔ－ａcegｉ—secuｒity。ｘmｌ

/WEＢ—ＩNF／apｐｌicａtioｎＣｏnｔext－ｃoｍmon—business.xml

/WEB—ＩNF/ａpplicaｔｉonCoｎtext-cｏmmoｎ—authorｉzation。xml

</pａram—value〉

〈/conｔeｘｔ—ｐａram>

这里列出了我们希望Ｓpring框架（Ａcegi中已经自带的Spｒiｎg）加载的关于Aｃｅgi的配置文件。

２.

定义了一个过滤器AcegｉFilｔerＣhaｉnProxy，〈ｆilｔer＞

＜ｆiｌter－ｎamｅ＞ＡcegｉＦilterChaiｎPrｏｘy〈/filteｒ—naｍe＞

<filtｅr—cｌaｓs>

net。sf。aceｇisecurity.ｕｔｉl.ＦilterToBeａnProｘy

＜／filter-ｃｌasｓ＞

<iｎit－ｐａraｍ>

＜ｐarａm—name>targetCｌａｓs＜/parａm—nａｍe〉

＜paｒam-valuｅ>

net。sｆ．acegiｓecuritｙ.util．FiltｅｒＣｈaｉｎPrｏxy

〈/paraｍ－ｖalue>

〈/init—paraｍ〉

＜/ｆｉlｔｅｒ＞

〈filter—mapping〉

＜ｆｉlteｒ—nａme〉AcegiFiｌｔerCｈaiｎPrｏxy<／filter—name＞

<uｒl—ｐａttern〉／*<／urｌ—patｔern>

〈/ｆｉlteｒ—mapｐinｇ＞这样的配置表时，当前ｗeb应用中的所用url的请求访问都会被这个过滤器捕获，也就是说，Acegi的页面控制其实和我们平时的开发一样,也是通过过滤器来实现的。

3.定义了两个监听器〈listｅner>

〈ｌiｓｔｅnｅｒ-class＞

org．sｐringframeworｋ.wｅb.cｏnteｘt.ＣontextLｏａdｅrLisｔenｅr

〈/listeneｒ－cｌａss〉

＜/listener＞

＜liｓｔener〉

<ｌistｅｎer—cｌaｓs>

nｅt。sｆ。acegiｓecurity.ui．ｓesｓiｏn。ＨｔｔpSeｓｓionＥvｅnｔPublｉsher

＜/ｌistenｅr—class＞

</ｌiｓｔener＞

第一个是用来动态加载我们前面定义的应用程序域的变量contｅｘｔConfigLocaｔｉｏｎ中所列出的配置文件的,第二个是Acegｉ内部需求使用的事件发布器，我们不需求太多关心它的实现和用法，就这样放着吧.

总的来说，这个工程本身也是以demo程序作为样板来建立的。

想了解更多信息,建议下载范例代码。

改造sｃhemａ通过Aceｇi的ｄeｍo演示大家可以看到，它所提供的缺省用户验证办法是依据的用户名和登录密码，而对于授权访问方面是根据用户所付于的角色来进行判断的。但在我们的业务系统中，用户验证则有所不同。单位号、用户ＩD和登录密码三者放在一起才能验证一个用户。同样对于用户角色的查询办法也得变成以单位号加用户ID为条件。我们先来看看Aｃegi所提供的dｅmo的表结构和表间关系.

CREATEＴAＢLEuseｒs(

usernａｍeVＡRCHAＲ(５0)NOTＮULＬPRIMＡＲYKEY，

pａsswordVARCHAR（50）NOTNULL,

enablｅdＢITNOTＮUＬＬ

）;

CRＥATETＡＢLEａｕthoｒｉｔｉes（

ｕsernamｅVARCＨAR(50）NOTNUＬＬ，

autｈorityVARCHAＲ（5０)NOTＮＵLL

）；

CREATEＵNIQＵEＩNＤEＸix_auth_usｅrnameONauthorｉｔies（usernaｍｅ，autｈority)；

ＣREＡTＥTABLEacl＿ｏbjｅct_idenｔity(

idＢIGＩＮＴGENERATEＤBＹDＥFAULＴASIDENTITY（STARTＷITH0)ＮOＴNUＬLPＲIＭＡＲYKＥY,

ｏｂjecｔ_iｄeｎtｉtyVＡRCHＡR_ＩGNORECASE（250）NＯTＮUＬＬ，

parenｔ_objecｔＢIGＩNT，

acl_ｃlassVAＲCHＡR_ＩGＮOＲECＡＳＥ(２50）ＮＯTNULＬ,

CＯNＳTRAINＴuｎiｑue_objｅｃt_idenｔityUNＩQUE(ｏbjeｃt＿idｅnｔｉtｙ)，

ＦOREＩGＮKＥY（paｒｅnt_oｂjeｃt）ＲＥＦＥREＮCESacｌ_objｅｃt_identiｔy（id)

)；

CREATETABＬEacl_ｐermisｓｉｏn（

idＢIGINTGＥNＥRATEＤBＹDEFAＵLTＡSＩDENTITY(ＳTAＲTWITH0)

NＯＴNULLPRＩMＡRYＫEY

ａcｌ＿ｏbｊecｔ_ideｎtitｙＢIGINTNOTNＵLL,

rｅｃipientVARCＨAR_ＩGＮＯRECＡSE（100)NOTNULL，

ｍａskINTEGERNOTNULL,

CONSＴRＡINTｕnique_ｒｅcipｉeｎtUNＩQUＥ（acｌ_ｏｂjecｔ＿ｉｄenｔｉty，ｒecipｉｅnt），

ＦOREＩＧNKEＹ（acl_obｊecｔ_ｉdeｎtity）REＦEＲENCESaｃl＿object_idｅntity(id)

)；

注意：以上sql语句来源于Acegi网站，应用于ｈｓqｌ。网页地址：

通过上面的scheｍa可以看出Acｅgi是如何管理用户和进行授权的。也就是说,如果要让其满足我们前面所提出的业务要求,第一步从schema这块就得进行改造。

我们业务上的实际要求很简单,还没有涉及到对象的方法访问的权限问题，只是想根据用户的角色来控制其页面和业务方法的调用。从而得到我们所需要的schema。

CREATETABLERS

（DWＨvａrchａr（2)ＮOＴNULＬ，

ＵSＥR_IDvaｒｃｈａr(5）NOTNULL，

USER_ＮAMEvarchar(20），

ENABLEDｖａrｃｈar（1）

,PRＩMARYKEY（DWH,

XＴBH,UＳER＿ID）);

CREＡTＥＴABLEdbo．aｕtｈoｒiｔieｓ

（DWHvａrchar(２）NOTNＵＬL，

USEＲ_IDvaｒｃｈar（5)NOTＮUＬL,

auｔhorityvarchａr（５０)NOTNＵLL

,PRIMARYKEY（DWＨ，

UＳＥR＿ID，ａuｔhｏｒｉｔｙ））；

注意:以上sqｌ语法为odbc格式。

到此，schema的改造完成，赶快到我们的数据库中实施它们吧。

改造登录页面我们要求,如果客户访问了我们声明要控制的页面,则将请求定位到登录页面,要求客户通过登录操作向系统表明自己的身份。下面就是我们在系统中使用的登录界面，它合demｏ自带的那个只有一点点区别,deｍo自带的那个只有用户名和登录密码两个字段，而我们的是单位号、用户ＩＤ和登录密码三个字段。页面最重要的源码如下：

<formacｔioｎ=”＜c：uｒlvalue=’ｊ_acｅgi_sｅcurity＿check’/>"ｍｅｔhod="PＯＳT"〉

<ｔable＞

〈tｒ><td〉单位号：〈／tｄ〉〈td＞＜ｉnｐｕｔtypｅ=’ｔexｔ'ｎame='ｊ_dｗh'＞</ｔｄ〉＜／tr＞

<tr〉〈td>用户IＤ:</td>＜td〉〈ｉｎputtype＝＇text'name＝'j_userid'〉</ｔｄ>〈／tr＞

〈tｒ〉<ｔd＞登录密码：</ｔd＞＜ｔd〉＜inputtype=＇pａsｓｗoｒd’naｍｅ=’j_pasｓworｄ’＞＜／ｔd〉<／ｔr>

<ｔr〉〈tdｃolｓｐａn=＇2’〉〈inputｎａｍe="submit＂type=”ｓｕbmit”〉<／tｄ>〈/tr＞

<tr〉〈tdcolｓpan＝'2'><=”ｒｅseｔ"tｙpe＝＂ｒeset＂＞<／td><／ｔr>

〈/ｔaｂlｅ>

＜/fｏrｍ〉大家可以看出,这个页面其实没有什么特别之处，只是根据我们的业务要求修改表单的定义罢了。有一点要注意的是Ａction的值是j_aｃｅｇi_secｕrity_ｃｈｅｃｋ，这个值我们将在ａpplicａtionContｅxｔ-aｃｅｇｉ—seｃurity.xml给出定义之所在，也就是说这里只是引用罢了。另外还有一点要注意的就是其中的三个字段值：j_ｄｗh、ｊ_useriｄ、j_password在后面的Acegi的代码改造中要用到的

ａpplicatiｏnCoｎtｅxt—aｃｅgi—security。xml配置说明及其实现先看看整体内容：〈beａns＞

<！－－＝==＝=＝======＝＝==========FILTＥRＣＨAＩN=＝==＝＝＝=======＝========--〉

<beａｎid="fｉlterCｈaiｎＰroｘy"

cｌaｓs="ｎet．sf。acｅgisｅｃuｒity。uｔil。FilteｒChａinＰroｘy”〉

〈ｐrｏｐeｒtynamｅ=”filterInｖocatiｏnDefinitioｎSourｃe">

〈ｖalｕe>

COＮＶERＴ＿URL_TO_LOWERCAＳＥ_BEFOＲＥ＿ＣOMPARＩSON

PATＴＥRN_TYPＥ＿ＡPACHE＿ＡNT

/＊＊=ｈttｐＳｅsｓiｏｎContextＩｎtｅｇｒatｉonFilter，ａｕｔｈｅnｔiｃationPｒocessiｎgFilｔer，basiｃPｒoｃｅｓsinｇFilｔer，anonymousPｒoｃeｓsiｎgFilter，secuｒityＥｎfｏrcementFiｌｔer

＜/vａlue〉

〈／propertｙ〉

〈/bean＞

〈!-—=====＝====＝=＝=＝======＝=＝ＡUTHENTICATION＝＝==============＝======——>

<beａniｄ＝＂ａｕthenticatiｏnMaｎager＂

class="neｔ.sf.aceｇｉsecｕｒity．ｐroｖｉdｅrｓ。ＰｒovideｒManaｇer”＞

〈propertｙname=”pｒｏviｄers”＞

＜lisｔ>

〈reflocａｌ=”dａoAutｈenticａｔionProｖiｄer"/〉

＜reｆlｏcaｌ=”anonymｏusAuthｅnticationProｖider＂/〉

＜/list＞

＜/prｏpeｒtｙ〉

〈/ｂｅａn>

<beanid＝”uｓerDＡO”ｃlaｓｓ＝"eｒDAO＂〉

<propeｒtｙｎaｍe=＂dataSourcｅ＂＞

〈refｂean=”dａtaSouｒcｅ＂／〉

〈／prｏperｔy＞

〈／bean〉

〈beanｉｄ=＂cachｅMaｎagｅr＂

clａss＝"ｃｈe.ehcacｈｅ.ＥhCａｃheＭanaｇeｒFacｔoryＢeaｎ”／＞

〈beanｉd＝＂userCaｃｈｅBackend”

clasｓ="che。ehcachｅ.ＥhCaｃｈeFaｃtoryBeａｎ"＞

〈ｐｒｏpertｙname=＂caｃｈｅMaｎageｒ”>

〈reflocal=”cacｈeManager”/＞

</proｐｅrtｙ>

<ｐropｅrtynamｅ=”ｃａcheNaｍe">

＜valｕe>userCache〈／value＞

〈/pｒoｐｅrty＞

〈/ｂeａn〉

<beanid="userＣache”

class＝”che．EhCacｈeBaｓedUserCache"＞

＜propeｒtyｎame=＂cache”>

〈ｒeｆloｃal="ｕserCacheBaｃkend"/>

</pｒoｐerｔy＞

<／bean>

〈bｅaｎｉd＝”dａoＡutheｎticatioｎＰroviｄｅr”

clasｓ="com。ｃｑｋyｉｎfo．ydxt.ａｃegi．dａｏ。PasｓwoｒdDaoAutheｎｔiｃaｔiｏnＰroｖｉｄer”〉

〈prｏpertynａｍe=”authentｉcaｔiｏnDao＂>

<reｆｌｏcaｌ=＂userDＡO"/＞

＜/ｐｒopertｙ〉

＜propeｒtyname=”ｕｓerCache＂＞

<refｌocａl=”uｓｅrCａｃhe”／＞

＜／ｐｒoｐｅrtｙ>

〈/bｅan>

＜！--ＡutｏｍaticａlｌｙrｅceivｅsAuｔhenticatioｎEvｅntmessaｇesfrｏmDaoAuthｅntiｃatioｎProviｄｅr—－>

〈beanid="lｏggerLisｔeneｒ”

clasｓ=＂nｅｔ.sf．acegiｓｅcurｉｖｉders.dao。eveｎt。LｏｇgerLｉstenｅｒ"／>

<beanid＝＂ｂasicPｒocessingＦilter＂

class="net.sf．acegisecurity.uｉ.baｓiｃａｕth．BasicPｒｏcessiｎgFiltｅr”>

＜ｐropertyｎａme=”auｔheｎticatiｏnManager”>

〈rｅfloｃal=＂autｈenticａｔioｎManagｅr"/>

</ｐropeｒty＞

〈ｐｒｏpertynamｅ＝"ａｕthenｔiｃatiｏnEｎtryＰoint">

〈rｅｆlｏｃal=”basicＰｒｏcessｉngFilterEntrｙPｏｉnt”/＞

＜／prｏｐerty〉

〈／ｂeaｎ>

＜beａnｉd=”basicＰrocessinｇFilterEntrｙＰoｉnt"

ｃlaｓs=”neｔ。sｆ。ａｃｅgisecurｉty。ui。basicaｕｔh．BasiｃPｒocessingFiｌterEｎtryPoint”〉

<propertyname＝"reａｌｍＮaｍe"＞

<valｕe〉ContacｔｓRealm<／ｖaｌue〉

</pｒopeｒty>

<／beａn〉

<beａniｄ=”anonymousPｒｏｃessingFｉlteｒ＂

claｓs=＂net.sf．aｃegisｅcurｉty．prｏvｉｄers.ａnｏnyｍous.ＡnonymoｕsProcessｉngFiｌteｒ">

<pｒopeｒtｙnａｍe＝"kｅy"＞

〈value>ｆoobａr〈/vａlｕe〉

〈/prｏpｅrｔy>

<propertｙnａｍe="userAttriｂｕte”>

＜valｕe＞anｏnyｍousＵsｅr，ROＬE_ANONＹMOUS〈/ｖａluｅ〉

<／property>

<／ｂｅan〉

＜beaｎid=”ａｎonyｍouｓAutｈｅｎtｉcationPrｏｖider＂

clａsｓ=”nｅt.sf.aceｇｉsecurity．ｐｒovｉders.ａｎｏnymouｓ．AｎoｎyｍoｕｓＡuthｅntiｃaｔionＰrovider"＞

＜prｏpeｒtynａme=＂kｅy">

＜vａｌue〉foｏbar〈／ｖalｕｅ＞

</ｐｒｏpｅrty＞

＜/bｅan>

＜beanid=”htｔｐSessionCｏntextＩntegraｔionFiｌｔer＂

clasｓ=＂neｔ．sf.aｃeｇiｓｅcｕｒity。context．HttpＳｅssionContｅxtInｔeｇraｔionFｉlter”>

〈properｔynａｍe="cｏｎｔeｘt"〉

<vａlue>

ｎet。sf。acｅｇｉｓｅｃurｉtｙ.contｅxt。sｅcurity.SeｃｕreCｏntextＩｍpl

〈／vａlue>

〈/ｐroｐertｙ>

＜/bean＞

＜！——=＝==============＝＝===HＴＴPREＱＵESTSECUＲＩTY===＝======＝======＝==—-＞

＜ｂｅａnid="ｓecｕrityEｎfｏrcementFilteｒ"

cｌaｓs＝＂neｔ．ｓf．acegiseｃｕritｙ．intercept。wｅb。SecuｒityEnfｏrcemenｔＦiltｅr”>

〈ｐroｐeｒtｙｎamｅ＝"ｆilterSeｃurｉtyIｎｔｅrceｐtoｒ"〉

＜rｅｆlocal=”fｉlｔｅｒInvocaｔiｏnIntercｅｐｔｏｒ＂/〉

〈/prｏperｔｙ>

〈pｒopｅrtynａme＝"autｈentｉcaｔionＥntryPoiｎt”〉

〈ｒeｆloｃal=”authenticaｔionProｃessingFilｔｅｒEntrｙPoint"/＞

</propertｙ〉

＜/beaｎ＞

〈beanid=”aｕtｈenticatｉonProcｅssingFiltｅr”

ｃlass＝＂coｍ。cqkyiｎfｏ.ydxt.ａceｇi．ui。weｂaｐｐ．AｕthｅｎｔicationＰroｃeｓsingＦｉlter”〉

<proｐｅｒtynaｍe="auｔhentｉcaｔionＭanager＂>

〈rｅfbean＝"authentｉcatiｏnManａger"／〉

〈／ｐｒｏperty>

〈ｐroｐertｙnaｍe＝"autheｎtｉｃationFailuｒeUｒl">

〈vａlue＞/ａceｇilｏｇｉn。ｊsp?lｏｇin_errｏｒ=１〈/valｕe〉

〈/prｏpｅrｔy>

〈prｏｐｅrtyｎame="defaultTargetＵrｌ”〉

〈valuｅ〉/〈/value〉

<／proｐｅrty〉

<ｐrｏpｅrtynａｍｅ＝”fｉlteｒPｒoceｓsesUrl”>

＜valuｅ>/ｊ_ａｃeｇi_sｅcuriｔｙ_chｅck</vaｌuｅ＞

＜/pｒopertｙ〉

＜/ｂeａn〉

＜beaniｄ=＂ａutｈenticaｔionＰrocｅssｉngＦilterEｎｔrｙPｏint”

class=＂ｎｅｔ。sｆ。acegｉsecurity。uｉ.ｗｅｂaｐp．AｕtｈｅnｔiｃａtｉoｎPｒocessiｎgFilterEntrｙPoint">

〈ｐroperｔynamｅ=”loginFormUrl"＞

〈vaｌuｅ〉/acｅｇiｌogin。jsp</vaｌue〉

<／pｒoperty>

＜ｐｒoｐerｔｙname＝"foｒceHttｐs”>

＜value〉false〈/ｖａlｕe〉

＜/ｐroｐｅrty〉

〈／beaｎ＞

〈beanid=＂httpRｅquesｔAccessDｅcｉsiｏnManaｇｅr"

ｃｌass＝＂nｅｔ．ｓf.acｅｇiｓecｕrｉtｙ。vｏte．AffｉrmatiｖeBaseｄ”>

〈pｒopeｒtyname＝"aｌlowIｆAlｌAbｓtaｉnＤeｃisions">

〈vａluｅ＞falｓｅ＜/valuｅ〉

〈/pｒopeｒtｙ>

<ｐropertｙnaｍe="decisionVoｔeｒs"〉

<lｉst>

＜ｒｅfbean=”roleＶoter"/>

</lｉst〉

〈/property〉

＜/bｅaｎ＞

〈!——NｏtetheoｒdeｒtｈaｔentrｉｅsareplaceｄaｇaiｎsttｈｅobjectＤefinitiｏｎＳｏurceisｃritiｃal.

TheFｉlｔerSecurｉｔyＩｎterｃeptｏrｗillwoｒkfｒoｍthetopｏfthelistdownｔoｔheFIRSTpａｔtｅrnthatmaｔchestherｅqｕestＵRL．

Accordingly,youshouｌｄplａceMOＳTSPＥCIＦIC(iea／b/c/d．*)exprｅｓsiｏnsfirst,withLEAＳTSPＥCIFIC（iｅa/.＊）expｒessioｎslasｔ—-＞

<ｂeanid＝＂ｆiｌterInvoｃatiｏｎInteｒcｅｐtor”

ｃｌass="nｅt.ｓｆ.aｃeｇercept。web.FｉlterＳecｕrityInterceptor”〉

〈proｐｅrtｙnａｍe="auｔｈｅntiｃatiｏnMaｎager">

<rｅｆbｅａn=＂autｈｅntiｃａtioｎManagｅｒ”/〉

</ｐrｏｐerty＞

〈ｐropｅrｔynａｍe="acｃｅssＤｅciｓionＭanaｇer”〉

〈rｅfｌocａl=＂httpＲequesｔAｃcｅssＤeｃiｓiｏnManａgｅｒ＂/>

＜／ｐｒopertｙ>

<propeｒｔyname=”objeｃtＤefiｎitioｎＳｏｕrce"＞

<vaｌue＞

CONVERＴ＿URL_TO_LＯWERCASE_BＥFＯRE＿ＣOMPＡRIＳON

PAＴTERN_TＹPE＿APAＣHE_ANT

/inｄex.jsp=ROLE_ANOＮYMＯUS，ROLE_ＳＵPERVISOR

/logofｆ．jsp＝ROLＥ_ANONYMOＵS,ROＬE_SUPERＶISOR

／aceｇiloｇiｎ。ｊｓp＊=RＯLＥ_AＮＯNYMOUＳ，ROLE_SＵPERVＩSOR

/＊＊=ＲＯLE_SUＰＥRVIＳOＲ

</ｖalｕe>

〈/pｒｏpｅｒty>

</bean>

〈/ｂeaｎs＞1.

FILTERCHAIN定义了beanfilteｒＣhainProxｙ，需求说明的部分是属性fiｌterInvｏcａtiｏnDefiniｔionＳourcｅ的值／＊*=httpSesｓiｏｎＣonｔextＩnteｇrａtiｏnFiｌter,aｕtｈeｎticａtiｏｎProcｅsｓingＦiltｅｒ,baｓicＰrocessingFｉlteｒ，ａnonymousProｃesｓingFilter，seｃuｒiｔｙEｎｆorcｅmentFｉｌter它表时我们的过滤器将引用的一系列Acegi服务。2。

ＡＵＴＨENTICATION定义了：a）

authentｉcatｉｏnManager,也就是认证管理器,这个在介绍部分有说明。它的ｐrｏviders属性我们在这里指定了两个:

ｉ.

一个是用于数据库认证的ｄａoAuｔhｅnticaｔionPｒovidｅrｂean

ｉi。

一个是用于匿名访问的ａnonｙmousAutｈenticationProvideｒ

ｂ)

userＤＡO,这个ｂｅan是我们自己所改造的，实现了我们前面说定义的sｃhｅma中uｓｅrs表和authoriｔｉes表的访问.在deｍｏ中，这个对象叫做jｄbcＤａｏIｍpl，而且是使用的Acｅgi的自己的实现，大家要注意一下。详情见源码。

ｐaｃｋaｇecｏm.cqkyｉnfｏ。ydｘt。aｃegｉ．dａo；

imporｔjaｖａ。sｑl。ＲeｓultＳｅt;importjava．sｑl.SQLＥxcｅpｔｉｏｎ;iｍpｏrtjavａ．sql．Types;imｐorｔｊａva.ｕtil。Ｌｉsｔ;

imｐoｒtｊavaｘ．ｓqｌ．DatａＳoｕrce;

ｉｍpｏｒtｎet．sf。acｅgisecuｒity．BadCreｄeｎtialｓExcｅpｔiｏn;iｍｐｏrtnet。sf．acｅgｉsｅcuｒiｔｙ．ＧｒaｎtedAuthoｒitｙ；ｉｍpｏrｔｎｅt.sf。aceｇｉsecurity.ＧｒａｎtedＡｕthorityImｐｌ;ｉmpoｒernaｍeＮｏtＦｏundExceptｉon;

iｍpoｒtorg。sｐｒiｎgｆｒａmewｏrk。dao.DａtａＡcceｓｓEｘceptｉｏn；ｉmporｔorg.springｆrａmeｗoｒk。jdbc.core.SqlPａrａmｅｔｅr;importｏrg。ｓｐrｉnｇfｒａmｅworｋ。jdbc。ｃore．supｐort.JdbcDaoSuｐｐorｔ;imｐｏrtorｇ.spｒingfｒameｗork．jdbｃ。obｊeｃt。MaｐpiｎgSｑlQuｅry；

ｉmportcom.ｃqkyinｆo．yｄxt．ａceｇi．IUsｅr；ｉｍｐorｅｒ;ｉmporｔcom。ｃｑkyｉnfo。yｄxt.ｂase．datａvｉsitoｒ。DTO；iｍｐoｒtｃｏm.cqkyiｎfｏ．yｄxt．exceｐtions.BusinessEｘcｅption;impoｒtｃom。cqkyinfo。ydxt。ｘtgl.businesｓ。XTGLBLFaｃａde；

publicclａssUserDＡOｅｘtｅndsJdbcDaoＳupｐoｒtiｍpｌeｍents

PａsswordAｕtｈenticatioｎDao｛

puｂｌicstaｔicｆinaｌStriｎｇDEF_AUTＨOＲITIＥS＿BＹ＿DWＨ_AND_ＵＳERＩＤ_QＵERY="SEＬＥCTdwh,user_id，aｕthoritｙFROMauｔhorｉtｉｅｓＷHEREｄｗh=?ANDuser_id＝？＂;

privａteMaｐpingＳqlQｕerｙａuthorｉtiesByDwhAndUseridMappｉng;

ｐublicUｓerDAＯ(）｛

super（）；

}

ｐublｉcＩＵserloaｄUseｒByＤwhＡndUseridAｎｄPassworｄ（Stringｄｗh，Stringuseriｄ,

Ｓｔｒingpassｗord)ｔhrｏwsＤaｔaAｃcesｓExceptiｏn，

BadCreｄｅntialsException｛

Usｅrusｅｒ=nｕlｌ；

tｒy｛

DTOdtｏ=XTGＬBLＦacade.getIｎstance()．getUserMａnageｒ（）．getLogiｎUsｅr（

dwh,useｒid,pａsｓwoｒd）；

StｒingenabｌｅdStｒ=ｄto.geｔＶａlue（”enａbled”)．ｔoStｒing（)；

booleaｎｅnableｄ＝faｌse；

if（enabｌｅdＳtr.ｅquaｌs（"1”）)｛

ｅnabｌed=ｔrue；

｝

ａutｈoｒitｉesByDwhAndUsｅrｉdＭappiｎｇ=ｎｅｗＡuｔhｏriｔiesByＤwhAndＵserｉｄMappinｇ（

geｔDataSource()）;

ＬisｔdbAuthｓ=autｈｏritｉｅsＢｙDwhAｎｄUｓｅridMappｉnｇ

．ｅxｅcｕｔe（nｅwSｔｒｉng［]{dwh,uｓerｉd｝)；

if(dｂAuｔhs．ｓizｅ（）＝＝0)｛

thｒownewＲuntiｍeＥxceｐtiｏn(”ＵserhasnoGrａnｔedＡuthoｒity”）；

}

GraｎtｅｄAｕthority［]ａrraｙAｕｔhs={｝;

ａrraｙAutｈｓ=(GｒaｎtedAuｔhoritｙ[]）ｄbAuths。toＡrray（arrayAuths);

ｕser=neｗUser(dｗh,useｒid，paｓsｗord,eｎabled，true，truｅ，true，

aｒrａｙAutｈs）;

｝caｔｃh(ＢｕsiｎeｓsExｃepｔｉｏne）｛

lｏgger.ｅrrｏr(e．getMeｓｓage（）);

}

retuｒnｕｓer;

}

/＊＊

*Quｅryoｂjｅｃttoloｏkupauser’ｓaｕthoritｉeｓ.

＊／

proteｃｔedclａssＡuthoｒitieｓByDwhAndUseriｄMapｐinｇeｘteｎdｓMappingＳｑlQuery｛

ｐrotectｅdＡutｈoritieｓＢyDwhAndUseｒiｄＭapｐing（DataSｏｕｒcｅds）｛

super（ｄs，DEＦ＿ＡUTHORＩTIEＳ_BY＿DWＨ＿ＡNＤ_UＳＥRID＿QUＥRY);

declareＰaramｅteｒ（newSｑlParａmｅtｅr(Types.ＶARCHＡR))；

ｄeclａｒeParameter（newSqlＰarameter(Tyｐｅs．VＡRＣHAR))；

ｃｏｍpｉle（）；

｝

prｏtecｔeｄObjectｍapＲｏw（ResultＳetｒｓ,ｉntrownum）tｈrowｓSＱLExceｐtioｎ{

ＳtrｉnｇroｌｅNaｍｅ=rs。gｅtSｔrｉｎg(３);

GｒaｎtedAuｔhoritｙImpｌauｔhority=nｅｗGraｎteｄAuthｏrityIｍpl(ｒｏleNaｍe）；

retuｒnautｈority；

｝

}

｝

ｃ)

cａchｅMaｎａger和ｕsｅrCachｅＢaｃkｅnd，这两大家一看就知道,我也是用的Ａｃegi的实现.

d)

useｒCａｃhｅ是我们自己改造的,原因是ｄeｍｏ中是以usernaｍe为标识来区别被缓存的对象的,而我们是dwh+userid.

详情见源码。paｃｋagcｈｅ；

impｏrcｈｅ;impｏrchｅEｘceｐtiｏn;importnet。sｆ.ｅｈcache。Ｅleｍent；

imｐormoｎｓ。logｇinｇ.Log；imporｍons.lｏgｇｉng．ＬoｇＦａctory；impoｒtoｒg．spriｎｇｆraｍewｏrｋ．ｂeans.factory．InitializingBean；iｍｐｏrｔoｒg.sｐringframeworｋ.dａo．ＤataRetriｅvalFaｉlｕreExcepｔion;

imｐｏ．ｃｑｋyinｆｏ．ydxt.aｃegi。IUser；

ｐｕｂlｉｃcｌasｓＥｈＣachｅBasedUsｅｒCａｃhｅｉｍpｌemeｎtｓUserCache,InitializinｇBｅaｎ｛

//～Stａｔicｆｉelds/initialiｚers==＝===＝======＝=========＝＝=＝===＝＝=＝===＝=====＝=

privaｔｅstaticｆinalＬoglogger=ＬｏgFａｃｔｏｒy.geｔLog（ＥhCａcheＢasedＵｓeｒCache．class)；

//~Insｔanceｆｉelds=＝===＝==============＝=＝===＝==＝======＝=＝＝＝==＝＝========＝=＝

ｐｒivateCachｅcache；

//～Mｅｔhods===＝=========＝＝==＝＝＝