如何在 CakePHP 中为站点功能构建内部访问控制

发布于 2024-11-04 07:50:20 字数 472 浏览 0 评论 0原文

我今天详细浏览了有关 CakePHP Acl 和 Auth 组件的教程和示例。我将 Auth 组件配置为使用 $this->Auth->authorize = 'actions'。这样我就能够成功地限制对特定站点操作的访问,没有出现任何问题。

但是,我的应用程序需要超出此范围,并且我不确定如何最好地实现此应用程序的目标。

在我使用 CakePHP 1.3.8 开发的应用程序中,有特定的“站点功能”。例如,应用程序的用户将能够互相发送消息。

我想将每条消息视为 ACO,以便我可以控制哪些人可以查看或删除该消息,哪些人不能查看或删除该消息。

网站的另一个功能是通过实现某些目标来赚取“徽章”。对于这些徽章,我想将它们视为 ACO,用于锁定和解锁这些徽章。

我认为我无法使用 CakePHP 的开箱即用 ACL 功能来做到这一点,因为这超出了限制对操作的访问的范围。我正在寻找有关如何最好地实现此功能的任何想法。

I went through the tutorials and examples on the CakePHP Acl and Auth components today in detail. I configured my Auth component to use $this->Auth->authorize = 'actions'. With this I was able to successfully restrict access to specific site actions without a problem.

However, my application needs to go a bit beyond this and I'm unsure of how best to accomplish my goals for this application.

Within the application that I am developing using CakePHP 1.3.8, there are specific "site features". For example, users of the application will have the ability to message one another.

I want to treat each message as an ACO so that I can control who can and cannot view or delete the message.

Another site feature is the earning of "badges" for achieving certain goals. For these badges I'd like to treat them as ACO's for the locking and unlocking of these badges.

I do not think that I can do this with the out-of-the-box ACL functionality of CakePHP as this goes beyond restricting access to actions. I'm looking for any ideas on how best to achieve this functionality.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

听闻余生 2024-11-11 07:50:20

使用 CakePHP 中的标准 ACL 功能,只能为控制器操作创建 ACO 条目。这意味着您的设置(将每条消息视为单独的 ACO)将无法运行。与徽章相同。

对于您的消息,我会进行一种设置,如果某个用户是消息的发送者或接收者,您将检查您的查看/编辑/删除方法。

就像关于徽章一样

# in messages_controller
function view($id) {
    if(!$isSender($loggedInUserId) || !$isReceiver($loggedInUserId)) {
        $this->Session->setFlash("You're not allowed to view this message")
        $this->redirect('index');
    }
    # do view stuff here    
}
function edit($id) {
    if(!$isSender($loggedInUserId)) {
        $this->Session->setFlash("You're not allowed to edit this message")
        $this->redirect('index');
    }
    # do edit stuff here    
}

,我会选择 UserBadge 之间的常规 HABTM (HasAndBelongsToMany) 关系。当用户达到某个目标时,您可以进行Badge::unlock($badge, $user)之类的调用,将用户的新徽章保存到>user_badges 连接表。

从那里您可以执行基本操作,例如列出特定用户的所有徽章等。

With the standard ACL functionality in CakePHP it's only possible to create ACO entries for controller actions. This means that your setup (treating every single message as a seperate ACO) will not fly. Same as with badges.

For your messages I would go for a setup in which you would check in your view/edit/delete methods if a certain user is the sender or receiver of the message.

Something like

# in messages_controller
function view($id) {
    if(!$isSender($loggedInUserId) || !$isReceiver($loggedInUserId)) {
        $this->Session->setFlash("You're not allowed to view this message")
        $this->redirect('index');
    }
    # do view stuff here    
}
function edit($id) {
    if(!$isSender($loggedInUserId)) {
        $this->Session->setFlash("You're not allowed to edit this message")
        $this->redirect('index');
    }
    # do edit stuff here    
}

Regarding the badges, I would go for a regular HABTM (HasAndBelongsToMany) relation between a User and a Badge. When a User reaches a certain goal, you make a call like Badge::unlock($badge, $user) which saves the new badge for the user to the users_badges join table.

From there you can do basic stuff like listing all the badges for a certain user, etc.

小ぇ时光︴ 2024-11-11 07:50:20

我更仔细地研究了 Cake 的 Acl 组件,并认为我可以为我的内部“功能”访问控制编写一些模仿此功能的东西。我的想法是我可以有一个 Faro(功能访问请求对象)、Faco 和 Facos_Faros 表。 Faco 和 Faro 将建立 HABTM 关系。然后我可以创建自己的组件来管理这一切。

I studied over Cake's Acl component much closer and figured that I could write something that sort of imitates this functionality for my internal "feature" access control. My thoughts are that I could have a Faro (Feature access request objects), Faco, and Facos_Faros table. Faco and Faro will have a HABTM relationship. I could then create my own component that manages it all.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文