棘手的类设计问题

发布于 2024-11-03 05:59:37 字数 1137 浏览 1 评论 0原文

我正在努力实现一个用于管理我的网站上的用户权限的类。

例如:员工可以查看客户记录,但不能查看其他内容,雇主可以查看客户并管理员工,管理员可以执行这些操作并管理雇主。

到目前为止,我得到的是这样的:

  • 我存储了一个权限列表,例如 addCustomerdelCustomer 等。每个权限都链接到一个允许执行该操作的用户角色列表。

  • 我已经构建了一个简单的权限类。我使用它是这样的:

    if ($permissions->can('addCustomer')) echo "添加客户"; 别的 echo '不允许添加客户';

然而棘手的部分是,在某些地方,我需要更具体。例如:客户获得了权限:readMsgs,该权限允许他读取自己与员工之间的消息。但是,如果他拥有该权限,那么他可以简单地将 URL 从: 更改

site.com/messages/read/100

site.com/messages/read/101

并读取消息 # 101,这可能是另一个客户和员工之间的消息。客户不应该能够阅读除他自己之外的任何人的消息。

同样,客户已获得 editCustomer 权限,该权限允许他通过以下方式编辑自己的个人资料:(

site.com/customers/99

其中 99 是他的客户 ID)

但是如果他转到 site.com/customers/100

不应允许他访问该页面。

我该如何解决这个问题?理想情况下,我希望能够将 id 传递给权限类。例如:

if (! $permissions->can('readMsg', $msgId))
   echo 'not allowed';

if (! $permissions->can('editCustomer', $requestedCustomerId))
   echo 'not allowed';

有什么想法我必须如何重组我的班级结构以允许上述事情发生?

I'm working on implementing a class for managing user permissions on my website.

For example: employees can view customer records but nothing else, employers can view customers as well as manage employees, and admins can do both those things as well as manage employers.

So far, what I've got is this:

  • I've stored a list of permissions, e.g addCustomer, delCustomer, etc. Each permission is linked to a list of the user roles which are allowed to do that action.

  • I've got a simple permissions class built. I'm using it something like this:

    if ($permissions->can('addCustomer'))
    echo " Add Customer ";
    else
    echo 'Not allowed to add customers';

However the tricky part is that in some places, I need to be more specific. For example: a customer has got the permission: readMsgs which allows him to read the messages between himself and an employee. However, if he has that permission, then he can simply change the url from:

site.com/messages/read/100

to

site.com/messages/read/101

And read message # 101 as well, which might be between another customer and employee. A customer shouldn't be able to read anyone's messages except himself.

Similarly, a customer has got the editCustomer permission, which allows him to edit his own profile by going to:

site.com/customers/99

(where 99 is his customer id)

But if he goes to
site.com/customers/100

He should not be allowed to access that page.

How can I solve this problem? Ideally I'd like to be able to pass on an id to the permissions class. E.g:

if (! $permissions->can('readMsg', $msgId))
   echo 'not allowed';

if (! $permissions->can('editCustomer', $requestedCustomerId))
   echo 'not allowed';

Any ideas how I'd have to restructure my class structure to allow the above kind of thing?

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

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

发布评论

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

评论(2

我是男神闪亮亮 2024-11-10 05:59:37

我会更详细地进行权限分类(例如,“readOwnMsgs”与“readAnyMsg”)。这将详细说明您的权限检查代码(例如,site.com/messages/read/### 的内容类似于“如果 canReadAnyMsg 或如果 canReadOwnMsg 且消息作者是当前用户则继续”),建议此逻辑应该是封装在按资源类型或任何可能影响做出此类决策所需的上下文信息的其他情况分解的单独类中。

I would be more granular in my taxonomy of permissions (e.g., "readOwnMsgs" vs. "readAnyMsg"). This would elaborate your permission-checking code (e.g., site.com/messages/read/### goes something along the lines of "proceed if canReadAnyMsg or if canReadOwnMsg and message author is current user"), suggesting that this logic should be encapsulated in separate classes broken down by resource type or whatever other circumstances might have an effect on contextual information required to make such decisions.

九歌凝 2024-11-10 05:59:37

我将有一个带有 canRead(User) 函数的消息类。这将检查用户的权限并说“哦,我是经理发给员工的消息。除非用户是消息的收件人,否则他们无法阅读它。”或者同样简单地“我是经理发给员工的消息。用户是经理,所以他可以阅读它。”

我用英文输入它,因为我很烂 php(这似乎是我选择的语言。)

I would have a message class with a canRead(User) function. This would check the user's permissions and say "Oh, I'm a message from a manager to an employee. Unless the user is the reciepient of the message, they can't read it." or just as easily "I'm a message from a manager to an employee. The user is a manager, so he can read it."

I'm typing it out in English because I suck a php (which appears to be the language of choice.)

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