09第八章︰迭代5︰用户访问控制.doc

第八章：迭代5：用户访问控制 像我们前面制作的TrackStar应用程序这样基于用户的web应用程序中，通常需要针对谁对某一功能提出访问请求进行访问控制。我们所说的用户访问控制是指在一个较高的层次上，当访问请求被提出时一些需要被思考的问题，例如： 请求的提出者是谁？ 提出请求的用户是否有足够的权限访问该功能？ 上述问题的答案可以帮助应用程序做出适当的响应。 在上次迭代中完成的工作使得应用程序有能力提出第一个问题。我们的基础用户管理应用扩展了应用程序的用户认证流程，使之可以使用数据库内的资料。应用程序现在允许用户建立自己的认证信息，并且在用户登录时使用储存在数据库内的信息进行匹配。在用户成功登录后，应用程序就知道接下来的一系列请求是谁提出的。 本次迭代的核心任务是帮助应用程序回答第二个问题。一旦用户提供了足够的认证信息后，应用程序需要找到一种合适的方法去判断用户是否有足够的权限去执行要求的操作。我们将利用Yii的用户访问控制中的一些特性来扩展我们的基本授权模型。Yii即提供了一个简单的访问控制过滤器，也提供了一个更先进的RBAC（基于角色的访问控制）体系，来帮助我们完成授权需求。我们将在TrackStar应用程序中用户访问需求的实现中仔细观察这2 点。 迭代计划 当我们在第3章第一次介绍我们的TrackStar应用程序时，我们曾提及，这个应用程序拥有2个高级别用户类型：匿名用户和认证用户。这是一个小小的区别基于成功登录的用户和未登录的用户。我们也介绍过用户在同一个Project中扮演不同角色的想法。针对一个Project我们建立了如下的三类角色模型： Project Owner（被赋予所有权限访问此Project的管理功能） Project Member（被赋予一定权限访问此Project的特性和功能） Project Reader (只有读取Project相关内容的权限，没有任何修改级权限） 这次迭代的重点是实施方法来管理这个应用程序中用户的访问控制权限。我们需要一个方法来建立我们的角色和权限，并且分发给用户，同时制定我们期望对每个角色施加的访问控制规则。 为了这个目标，我们需要标明所有我们将在本次迭代中完成的项目细节。下面的列表是这样一个项目列表： 制定一个策略来强制用户在获得访问任何Project或Issue相关功能前，必须登录 建立用户角色并且使之与一个特殊的功能权限对应 制定一个为用户分配角色的机制（包含角色相关的权限） 确保我们的角色权限结构针对每一个Project独立存在（也就是说，允许用户在不同的项目拥有不同的权限） 制定一个让用户和项目，同时也和项目中的角色相关联的机制 实施适当的认证访问检测，使得应用程序可以针对基于不同用户权限进行允许或拒绝访问操作 幸运的是，Yii内部有大量内部功能可以帮助我们完成这一需求。所以，让我们大干一场吧。 运行已存在的测试套件 如常，是时候运动一下了，我们需要运行一次所有已存在的单元测试，来确保测试可以通过： SHELL代码或屏幕回显： % cd WebRoot/protected/tests/ % phpunit unit/ PHPUnit 3.4.12 by Sebastian Bergmann. Time: 3 seconds OK (10 tests, 27 assertions) 一切都没有问题，所以我们可以开始本次旅程了。 访问控制过滤器 我们曾经在第三次迭代的时候介绍过过滤器，当时我们使用它来鉴别项目上下文关系，当处理Issue相关CRUD操作时。Yii框架提供的过滤器被叫做 accessControl(访问控制)。这个过滤器可以被直接使用在控制器类中，提供一种授权方案来验证用户是否可以使用一个特定的控制器下的行为。实际上，细心的读者应该能想起，我们在第六章使用filterProjectContext过滤器时，我们曾发现过，访问控制过滤器当时已经存在于 IssueController和ProjectController类的过滤器列表中，像下面的样子： PHP代码： /** * @return array action filters */ public function filters() { return array( accessControl, // perform access control for CRUD operations ); } 上面的代码包含在由Gii代码生成器在生成Issue和Project AR类的脚手架CRUD操作时，自动生成的代码里的。 默认的实现方法是设置为允许任何人观看一个已经存在Issue和Project项目的列表。然后，它只允许认证用户进行新建和更新操作，进一