Idiomatic way to model policies with object + receiver?

Casbin = way to authorization

A place for Casbin developers and users

现在注册

已注册用户请登录

主题样式选择

默认主题样式 ✅

知乎主题样式

这是一个创建于 1911 天前的主题，其中的信息可能已经有所发展或是发生改变。

Example

Hello,

Consider an app that allows users to bookmark GIFs and send them to others. By default, Alice can send any GIF she wants to any other user in the system:

p = sub, gifID, act

p, alice, *, save
p, alice, *, send

Problem

But sending GIFs involves two people -- not just Alice. What if Alice wants to make sure she never sends a GIF to Bob?

Possible RegEx Solution

Would the policy (ignoring "save") be modelled as:

[policy definition]
p = sub, gifID, act, recipient

p, alice, *, send, <Some regex for "everything except Bob">

m = r.sub == p.sub && r.gifID == p.gifID && RegexMatch(r.recipient, p.recipient)

Doubts

Using a regex match seems a bit suspicious to me. Does the regex grow for every user that Alice blocks? ^(Bob|Charlie|...). Is it a performance concern?

And if regex is the correct way to go, it feels a bit clumsy because the "recipient" field only applies to the "send" action, and not "save".

Further

Any general help on this would be appreciated, especially if there is an idiomatic way to get systems to support:

both objects and receivers
blocking/whitelisting receivers
blocking/whitelisting specific GIFs

214 次点击 ∙ 1 人收藏

Tweet Weibo 忽略主题

2 条回复 • 2020-09-11 00:26:14 +08:00

cjea5年前

Maybe this should really be an RBAC system? Should Alice be a gifSender? And if so, does that make modelling the object + receiver easier at all? I appreciate any suggestions

hsluoyz5年前

Hi @cjea, sorry for the late response.

Using a regex match seems a bit suspicious to me. Does the regex grow for every user that Alice blocks? ^(Bob|Charlie|...). Is it a performance concern?

I think your regex way is not bad. There are also some other alternatives:

Define a custom function like isBlockingUser(userA, userB), so you can define your own logic inside it and use it in the matcher or policy (with eval()).
Use the deny-override model, define each blocked user as a policy, like:

p, alice, *, send, bob, deny

And if regex is the correct way to go, it feels a bit clumsy because the "recipient" field only applies to the "send" action, and not "save".

You can use keyMatch() or regexMatch() to wrap two actions into one: send|save