sword's blog

用Acegi Security来保护Grails应用

2008-08-20T01:25:00.000-07:00

本文论述了grails-acegi plugin与一个简单Grails应用的集成。集成使用了三个主要组件——Groovy, Grails和Acegi Security.

建立RaceTrack例子应用

首先，你需要下载Grails 1.0、grails-acegi-0.2 plugin以及Java SE JDK 5.0或更新版。

这里，我们假定你已经实现了Grails入门指南中所描述的RaceTrack应用的大部分功能。但是，为了测试grails-acegi plugin，你不必完成整个指南。测试grails-acegi plugin所需的全部东西包括：领域类（domain classes）和controller，controller的脚手架对于测试来说已经足够了。

图 1 —— 创建racetrack应用后的目录结构

你的RaceTrack应用目录看起来应该和图1显示的类似。现在，打开\grails-app\domain目录：

图 2 —— 领域类目录

正如你从图2中看到的，“domain”目录只包含了两个domain类：Race和Registration。现在，打开\grails-app\controllers目录，确认一下每个domain类都有一个对应的controller，如图3所示：

图 3 —— Controllers目录

这些controller可以是空的、脚手架（scaffold）controller，例如：

  class RaceController { def scaffold = Race }

class RegistrationController { def scaffold = Registration }

这足以让程序跑起来了。在你开始运行RaceTrack应用之后，你将能够在如图4所示的contoller list中看到两个你所创建的controller：

图 4 —— 使用Grails-Acegi Plugin之前的首页

安装Grails Acegi plugin

下一步是安装grails-acegi plugin，这样RaceTrack就可以利用该plugin所提供的基于角色的安全防护。在命令提示行中，进入到“racetrack”目录并运行如下命令：

grails install-plugin [path-to]/grails-acegi-0.2.zip

这一命令会在“racetrack”目录下创建一个plugins目录，如图5所示：

图 5 —— 安装plugin之后所创建的plugins目录

创建Acegi Security组件

下一步是创建代表用户帐号（Accounts）和角色（Roles）的领域类。运行如下命令开始这一过程：

grails create-auth-domains AuthUser Role

这一命令将创建两个领域类（AuthUser和Role）、建立AcegiConfig类、并创建Login和Logout两个 controller。AuthUser领域类代表你的用户，因此每个新用户都将在Auth_User表中创建一条新的记录。Role领域类代表每个用户所拥有的安全角色，Role将被指派给AuthUser。所有这些类都显示在图6中。

AcegiConfig类（图7）定义了你的应用的安全配置。配置中包括：用户领域类的名字（本例为AuthUser）以及角色领域类的名字（本例为Role），使用动态还是静态安全Urls，怎样设置email警报（打开或关闭它们）。

图 6 —— AuthUser.groovy、Role.groovy和Requestmap.groovy（在AcegiConfig中使用）

图 7 —— 已创建的AcegiConfig.groovy

为了创建新的AuthUser，创建新的Role并指派给AuthUser，我们还得运行两个命令。其一是产生领域类的CRUD控制：

grails generate-manager

第二个是为controller和domain产生registration：

grails generate-registration

这些命令给了用户注册并创建其用户名和口令的能力，默认的安全角色将被指派给该用户。从图8可以看到所产生的这一controller集合：

图 8 —— CRUD controllers （Login和Logout controller是在AuthUser和Role被创建的时候创建的）

图 9 —— 安装grails-acegi-plugin之后可用的Controller

访问RaceTrack首页——它看上去类似于图9所示内容。

配制Acegi Security来保护应用

我们现在创建一个用户角色和管理者角色——首先点击RoleController，输入角色名“user”以及角色描述（图10）。注意 RoleController将会把“user”转换成“ROLE_USER”，数据库中和Acegi的配置中将使用“ROLE_USER”。重复同样的步骤创建一个管理者角色。

图 10 —— 创建一个用户角色

回到首页，点击UserController。现在创建一个拥有“user”角色的用户和另一个拥有“manager”角色的用户，如图11所示：

图 11 —— 创建一个标准用户，激活该帐户并为其指派“user”角色

我们创建的角色和用户现在已经足够用作配置了，下一步是保护RaceTrack应用。有两种方法保护你的URLs：一种是动态，通过 RequestmapController来实现；另一种是静态的，直接编辑AcegiConfig.groovy文件。动态配置是被推荐的选项，下面我们继续进行动态配置工作。

在我们保护应用之前，需要考虑一下应用需要给予怎样的访问规则。一个manager被允许读/写访问应用中的任何页面，即：

/race/*
/registration/*

一个用户被允许只读访问某些页面，包括：

/race/list/*
/race/show/*
/registration/list/*
/registration/show/*

这些规则需要使用RequestmapController翻译成Acegi请求映射（Acegi request map）中的条目。从RaceTrack首页上点击RequestmapController，转到“create a new requestmap”页面。在URL域内填写上“/race/**”，在Role域填写为“manager”（图12）——这将创建一条规则，允许任何拥有manager角色的用户访问/race下的所有URLs。同样的方法可以配置好registration（URL：/registration /**）。

图 12 —— Manager访问规则

注意，一个好的习惯是给manager角色也授予所有用户权限。下一步将给用户角色创建访问规则——在URL域输入“/race/list /**”，在Role域输入“user, manager”（图13——注意角色之间是用逗号分隔的）。这一步骤将创建这样一个访问规则——允许user和manager角色都能访问race列表页面。注意这两个角色你都需要指定——如果你只将该URL指派给user角色，它将覆盖前面给manager指派的规则，这样只有user角色才能访问该页面。为前面定义的其他规则重复这一步骤——这将为race和registration页创建所有的访问规则。

图 13 —— 为/race/list/**页面创建规则——准许user和manager角色访问

测试

在RaceTrack首页上点击RaceController或RegistrationController（我们已经保护了这些 controller）。你将注意到页面自动重定向到了Login页面。如果你先以manager角色的用户登录，你就能够浏览、创建、更新和删除 race和registration页面的任何东西。

图 14 —— 以一个user身份登录

回到RaceTrack首页并点击LogoutController——这将使你的用户session失效并登出。再次点击LoginController，但是这次以user角色的用户登录。如果你转向/race/list的子页面（直接访问http://localhost:8080/racetrack/race/list或通过controller转过去），你将看到race/list视图（图15）。

记得么，访问规则只允许manager创建新记录，user角色只允许从List和Show页面读取数据——这意味着如果你以user角色的用户登录并点击了New Race（http://localhost:8080/racetrack/race/create），Acegi将阻止你浏览该页面，它阻止了一个新记录的创建。

它是怎么工作的呢？回想一下，我们给manager角色授权可以访问/race/*，但是只给user角色授权访问/race/list/*和 /race/show/*。当拥有“user”角色的用户试图访问/race/create页面时，Acegi察看该用户所拥有的所有角色，发现其只有 “user”角色——因为我们的Request map说了，必须是“manager”角色才被授权访问这一页面，于是访问这一页面的许可被禁止了。

顺便讲一下，在一个真正的应用中，你可能想要显示一个比默认错误页（图16）更好看的错误页。

图 15 —— Race List视图

Figure 16 —— 访问禁止错误页

恭喜你——现在你已经有了RaceTrack应用的一个完整的安全实例了！

查看英文原文：Securing a Grails Application with Acegi Security

转自infog 作者 Fadi Shami译者宋玮

CMM之道：一个愚蠢农夫和奶牛的故事

2007-03-18T18:55:00.001-07:00

Ivar Jacobson博士他被认为是影响或改变了整个软件工业开发模式的几位世界级大师之一，是软件方法论的一面”旗帜”。他是组件和组件架构、用例、现代业务工程、Rational统一过程等业界主流方法或技术的创始人。

　　
　　Ivar Jacobson博士认为，如果采用不良的软件过程，通过CMM/CMMI的成熟度级别越高，只会使软件企业生产不合格软件的过程更加有效率，而不是使企业开发出更好的软件。
　　
　　软件外包是时下的一个热门话题，被我国不少软件企业视为一座金矿，而CMM被人们认为是进入这个市场的敲门砖，为了拿到那张代表资格的CMM认证证书，不少企业甚至不惜投入数百万之巨。事实上，拿到CMM认证在国外并不代表企业就能提供一个合格的软件，著名的软件专家、拥有组件技术、用例技术等多项发明、与Grady Booch、James Rumbaugh一起被称为UML之父的Ivar Jacobson博士在近期访华期间一再提醒中国的软件企业，谨防掉入CMM陷阱。

CMM/CMMI的缺点
　　
　　CMM/CMMI最早起源于美国国防部。为了改变在采购过程中频繁地采购到大量不合格软件的局面，美国国防部需要一种评估软件质量的方法，这就是要求软件企业进行CMM/CMMI认证。然而，CMM/CMMI真正解决这个问题了吗？
　　
　　CMM/CMMI被认为是一种最成熟、最有效地提高软件工程化水平的方法和标准，用来评估和改进过程，它是一个描述在软件开发过程中有待改进的丶蛩氐目蚣埽枋隽艘桓瞿苡媒ソ绞浇懈慕耐揪丁Ｋ砑谈慕峁┮桓龌。砑⒋右桓鱿喽岳此邓嬉狻⒉怀墒斓墓瘫涑煞浅３墒斓摹⒂泄媛傻摹⒖ 晒芾淼墓獭?lt;BR>　　
　　然而，CMM/CMMI也有一些与身俱来的缺点不容忽视。比如，CMM/CMMI的评估耗资不菲，一个 CMM2级评估就可能达到数百万之巨，而且耗时很长，过程十分复杂，常常导致效果不太理想。不少企业的认证流于形式，评估完成后就只留下一大堆文档，而真正的软件开发过程却依然故我。而且，CMM/CMMI只告诉我们应该怎么做，而没有具体地告诉如何做。比如说，它要求必须改进需求管理，那么到底该如何做需求管理？CMM/CMMI没有提供答案。
　　
　　还有最重要的一点是，不少软件企业陷入了一个误区，以为单单通过CMM/CMMI评估就可以解决软件质量不高的问题，而忽略了软件过程这一真正改善软件质量的环节。事实上，完全有可能出现这样的情况: 软件成熟度为CMM 1级或2级的企业开发出的软件是真正好用的，而有的企业即使通过了CMM 5级认证，也无法保证它交付好的软件。最糟糕的情形是，如果采用不好的软件过程，通过CMM/CMMI的成熟度级别越高，只会使软件企业生产差劲软件的过程变得更加有效率，而不是使企业开发出更好的软件。
　　Ivar Jacobson认为,好的软件过程首先一定是基于组件的,在此基础之上,还要符合迭代开发、用例驱动开发和以架构为中心的这三个最佳实践。

合理的软件过程是软件质量的基础
　　
　　为什么会是这样呢，Ivar Jacobson举了一个非常形象的例子。这是一个农夫和他的奶牛的故事。在奶牛喝水的途中（称为”牛路”）有一片庄稼地，牛会吃掉很多庄稼。农夫看到这种情况后，意识到必须对奶牛喝水的过程进行改进，所以他就在这条道路上铺上了沥青。结果，农夫得到了一个好的”牛路”，牛走得更快了，但是并没有真正解决牛吃庄稼的问题。它应该有更好的方式，就是为牛喝水寻找一条全新的道路。

　　软件企业利用CMM框架进行软件质量控制的过程，就像是这个农夫为牛路铺沥青。对于软件企业来说，如果从一个错误的软件过程开始，即使你在这个上面再改进，得到的永远只是”牛路”。这里更应该考虑的是要选择一条更好的路，也就是从一开始时，就采用能够开发出好的软件的过程。然后在这个软件过程的基础上，对这个软件进行度量，改进这个软件的过程,也就是进行 CMM/CMMI要求的改进。

　　Ivar Jacobson博士认为，从一个不良的软件过程出发，在此基础上进行改进，实际上会把软件开发变得更糟糕，因为你把软件开发过程固化了，使日后再想对它进行改造，变得更加困难。正确的方法是，先要有一个好的软件过程，这是不容易的，但是值得做的事情。

　　Ivar Jacobson 说，”把一个好的软件过程变得可度量非常容易，但是把一个可度量的软件过程变成一个好的软件过程却很难”。也就是说，只有把一个好的软件过程，即能够开发出好的软件的过程变得可度量才是有益的。而把一个已经经过CMMI改进的、可度量的过程变成一个真正的能够开发出好软件的过程，这是几乎不可能的事情。
那么什么是一个好的软件过程？Ivar Jacobson建议从以下几个方面进行辨别:

1 坏的过程关注文档上，而好的过程关注在可执行的程序或者系统上;
2 坏的过程延误了揭露风险的时间，而好的过程一开始就把自己暴露在风险之下，并及时解决它;
3 坏的过程在项目的最后才能够验证这个项目的质量，而好的过程其质量是每时每刻都能够得到验证的;
4 坏的过程有一个非常复杂的跟踪关系矩阵，从需求到代码需要一个非常复杂的矩阵，而好的过程，却是一个无缝链接;
5 在面对变更时，坏的软件很脆弱，好的软件会很健壮。
　　
　　Ivar Jacobson提醒软件开发人员要做聪明的农夫，首先得到一个正确的软件过程; 然后，再考虑去度量它、定义它。因为软件项目管理的本质不是能否描述并度量软件过程以及过程到底怎么样，而是首先关注软件，你是否能很好地开发出合格软件。重点是得到结果，通过软件过程得到这个结果，也就是交付的软件产品。

观点碰撞－敏捷开发企图终结软件危机
　　
　　如今在软件开发领域占绝对主流地位的传统软件工程学思想是大约在20世纪60年代伴随着”软件危机”言论的出现而诞生的。所谓软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题，它包含两方面内容：一是如何开发软件，以满足不断增长、日趋复杂的需求；二是如何维护数量不断膨胀的软件产品。的确，传统软件工程学思想的诞生，把软件开发活动按照工程化的原则和方法进行组织，并一度被认为是摆脱软件危机的一个主要出路。
　　
　　但是，数十年后的今天，人们对于软件危机的”恐惧”仍没有丝毫减弱，相反随着软件系统的急速膨胀而越发不可收拾了：对软件开发成本和进度的估计常常不准确，开发成本超出预算，实际进度比预定计划一再拖延的现象并不罕见；用户对”已完成”系统不满意的现象也经常发生；软件产品的质量往往靠不住，Bug一大堆，补丁一个接一个；等等。于是，无论是产业界还是理论界，都开始对传统软件工程学思想产生怀疑，甚至背叛。因此，关于软件到底是”工程”还是”艺术”的讨论一度风靡全球。而以迭代式循序渐进开发方式为主，以”人”为核心的敏捷开发方法就是在这样的背景下产生的，它背叛了传统软件工程学中以”过程”为核心，把设计和开发尽可能分开，尽量弱化”人”在整个工程中地位的思想。
　　
　　近日，当世界软件开发领域最具影响力的五位大师之一、敏捷软件开发方法的早期开拓者马丁·福勒先生来华与国内软件高手论道之际，北京大学软件学院院长阵钟老师再次将软件是”工程”还是”艺术”这一问题摆到了桌面上。而这位软件教父似乎对这一问题早有深入思考，他认为，这一争论的核心应该在于软件设计是否要与软件开发分开，这也正是传统工程化软件开发方法与敏捷软件开发方法的重要区别。
　　
　　作为敏捷软件开发方法的推动者，马丁先生认为，软件设计应该和软件开发紧密结合在一起，采用迭代式开发。软件开发不能被认为是一个既定的过程，因为软件开发中有太多的变化出现，既定的过程设置不可能达到合适的预想结果。由于需求变化、技术更新、人员流动等问题的存在，许多软件设计工作应该在软件开发到一定程度的时候才能进行，两者不应该在顺序上严格分开。他说:”至于从哲学的角度讲，到底软件开发活动是艺术还是工程呢？我很难清晰地界定，也许都是或者都不是。也许我们应该把软件开发活动当做一个独立的东西来对待。”
　　
　　由此看来，马丁先生既不认为软件开发活动应该是一个先进行设计，然后根据 “设计图纸”进行构建的工程化过程，也不认为软件开发应该是完全依赖于开发者头脑中随时蹦出的灵感的艺术活动，因为这两种倾向在人类数十年的软件开发实践中已经被证明都不甚完美。而他企图在两者之间找到一个均衡点，这个均衡点也许正是真正解决”软件危机”的突破口。
　　
　　据了解，敏捷开发实际上包括了许多优秀的软件开发习惯。首先，这种方法改变了软件测试的流程，在编写代码前进行测试，减少了开发风险；其次，可以对软件进行持续集成，即每个小时都在集成，任何部件间的冲突都可以随时解决；此外，这种方法的”动态规划”和”重构”做法，意味着开发者可以对软件架构进行持续改进，可以根据用户的需求随时进行改进，而利用传统的软件开发方法则很难对软件的架构进行调整，同时也会造成成本的大幅增加。