问Zend Auth和ACL

EN

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

我处理这个问题的策略是创建我自己的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教程左右您自己的模型。它们只是一些简化的例子。

努夫说