问Zend Auth和ACL

EN

我推荐Manning Publications的"Zend Framework in Action“这本书，作为对此的最新介绍。它以PDF下载的形式提供，所以您现在可以使用它:)

但要回答这个特别的问题：

让我们从定义两个关键术语开始。Zend_Auth中的“身份验证”指的是身份验证，它证明某人是他们所说的那个人(即登录)。Zend_Acl中的"A“指的是授权，它证明某人有权做他们想要做的事情(即访问控制)。

假设用户只有一个角色...将用户的角色存储在您作为Zend_Auth的一部分获得的“身份”中。登录时：

$auth = Zend_Auth::getInstance();
$identity = new stdClass();
$identity->user_pk = $user->getPrimaryKey();
$identity->user_name = $user->getName();
$identity->role = $user->getRole(); // select * from user_role where user_pk=xxx
$auth->getStorage()->write($identity);

在控制器中：

$acl->add(new Zend_Acl_Resource('news'))
->allow('defaultRole', 'news');

默认情况下，所有内容都被拒绝，因此您实际上不需要指定：

->deny('defaultRole', 'news', 'add');

在控制器的代码中进一步介绍：

$identity = Zend_Auth::getInstance()->getIdentity();
if(!$acl->isAllowed($identity->role, 'news', 'add'))
{
   header('Location: http://www.yoursite.com/error/unauthorized');
}

如果用户的身份不被允许做“新闻->添加”，它会将他们重定向到未授权的页面(假设您已经创建了这样一个页面)。

如果用户有一个以上的角色，您将在他们的身份中存储一组角色。那么你的支票应该是这样的：

$identity = Zend_Auth::getInstance()->getIdentity();
$isAllowed = false;
foreach($identity->role as $role)
{
   if($acl->isAllowed($role, 'news', 'add'))
   {
      $isAllowed = true;
   }
}
if(!$isAllowed)
{  // if NO ROLES have access, redirect to unauthorized page
   header('Location: http://www.yoursite.com/error/unauthorized');
}

希望这能有所帮助。

是的，在大多数情况下，您的所有身份验证都应该通过同一个控制器。但是，Zend Auth不是控制器类型。Zend Auth是一种API，用于利用常见的身份验证方法，如数据库或http。它的工作实际上只是对编写身份验证代码这一繁琐的工作进行包装。

Zend Acl是用于区分普通用户和特权用户的Acl。只有在用户通过身份验证并登录后，才会涉及Zend Acl。

您需要的大部分内容都在ZF文档中。我阅读了几乎所有关于Auth和Acl的文档，直到它对我有了很大的意义。尽管ZF的Auth、ACL、Storage_*和其他类非常紧密地结合在一起使用，但它们都具有非常不同的用途。稍等片刻，您就会发现它们彼此之间建立得很好。

以下是帮助您入门的几个链接：

Pádraic Brady's ZF Tutorial

Zend's DevZone article on ACL and MVC

我能理解你为什么会感到困惑。我当时/现在还有点困惑。所以，很遗憾，我不能直接回答你的问题。但是，为了澄清我头脑中所有这些东西，我正在做的一件事是从“域对象”的角度来思考，而不是数据库记录。

我处理这个问题的策略是创建我自己的Auth Adaptor，它与用户凭据一起传递一个“user Base Object”。我的“用户基础”有点像是用户的仓库。

因此，Zend Auth是其他Zend组件的“接口”，而我仍然可以更多地控制我的系统来存储和访问“用户”。我的User_Base类可以是Zend Db tbl的包装器，甚至可以只包含一些用于测试的硬代码。

所以大体上-

• 设计您自己的“用户”模型
• 设计您自己的身份验证适配器-从下面列出的所需的最低接口开始：

只需保持一切简单，并随着您了解更多信息而慢慢进行。

不管怎样，这就是我要做的。

我甚至不会费心使用Zend ACL，直到我头脑中的Auth清楚了。

我正在改造一个遗留站点，并将其转换为Zend MVC

为了让我的“模型”发挥作用，我必须掌握一些东西(可能是非常规的)。：

• 应用程序可能会被来自多个“用户群”的用户使用- openID、遗留用户表、新用户表、转瞬即逝的访客等。而访客的身份可能只是他们第一次访问遗留用户时创建的哈希，而遗留用户的身份可能由遗留用户表中的id表示。
• users

user_accounts是两个不同的东西。不要试图将它们混合在一个概念中，因为它可能会得到complicated.

• there，可能是系统中许多不同类型的帐户。即买方帐户与卖方帐户。Readers_Account与Writers_Account
• 帐户“有”用户-“主要帐户持有人”、“管理员超级用户”等
• 用户和帐户之间的关系由例如“account_users”(所有用户群中所有用户的本地子集)表示。
• 角色附加到account_users(该特定帐户的用户)。(与四处浮动的角色相对)
• 不害怕在服务器上有多个Zend应用程序来表示网站-例如，管理应用程序、成员应用程序、前端应用程序。

应用程序不会害怕让这些应用程序使用存储在例如“共享模型”文件夹中的模型对象，只有与单个应用程序直接相关的模型代码位于/

• /models/foomodel folders.
• each应用程序可能有其自己的自定义身份验证适配器
• 管理员身份验证适配器可能只允许来自“管理员用户表”的用户，而前端应用程序的身份验证适配器可能能够验证来自访客用户库、工作人员、或者成员用户群。
• 可能是一个特殊的情况，当成员登录时，前端应用程序会话被清除，并由成员会话复制。
• 在任何时候每个when客户端每个应用程序都有一个用户对象(而不是试图引用一个具有访客用户和成员用户的人-这是每个应用程序每个用户的会话太多(命名空间以避免与他们可能登录到该域的其他应用程序冲突)-(而不是试图通过访客会话和成员会话同时引用“使用它的人”。再说一次，这太complicated)

了

好的，我开始ramble....but了，你明白了。不要让您看到的Zend_Auth+Zend Db教程左右您自己的模型。它们只是一些简化的例子。

努夫说