Acx - An Access Control library similar to Casbin

Hello everyone! It’s Corona time and it sucks! I don’t know about you but being alone and having plenty of time to code, to learn new things is, to me, a blessing in disguise ^_^.

This library came to being when I was working on project management system app, and I though it may be useful to some of you. So, please check it out if you have some spare time. I would love to hear your thoughts / feedbacks about it.

Acx

Thanks!

7 Likes

Seems interesting but I do not like the format really. The “shortcut” names seems a little bit pointless and confusing (it took some time for example to understand that eft is from effect). That one letter names seems really confusing.

Could you describe the differences between using this and OPA or just Erlog?


About API, I would change the start_enfircer/2 to take config as a first argument, and keyword list as a second where you could specify :name option if needed, as sometimes it is easier to operate with PIDs than names.

Hey @haulet, thanks a lot for your feedbacks.

Seems interesting but I do not like the format really. The “shortcut” names seems a little bit pointless and confusing (it took some time for example to understand that eft is from effect ). That one letter names seems really confusing.

The reason for this naming conventions is that I want to adopt the naming conventions used in Casbin, so that users of Casbin would find it at home. By the way, the eft attribute is implicitly the last attribute for all policy rules, so users don’t have to define it in their policy definitions.

Could you describe the differences between using this and OPA or just Erlog?

I don’t know much about Erlog, but regarding Open Policy Agent, you could read their RBAC example and compare it with the one in Acx, you’ll understand the difference. In a nutshell, the main difference between Acx and others is the separation of concerns between concrete policy rules (which is like your data) and matching logic (your program).

About API, I would change the start_enfircer/2 to take config as a first argument, and keyword list as a second where you could specify :name option if needed, as sometimes it is easier to operate with PIDs than names.

Thanks! That’s a good option to consider. In a situation like ours, which is a project management system, we need an enforcer for every single workspace created, so if using PID we have to {:ok, pid} pattern match every time launching a new enforcer, save it somewhere, and look it up whenever we need to contact the enforcer of a workspace. But if the workspace name is unique, why not use it to name the enforcer associated with it, so we don’t have to look it up anymore (e.g making a trip to the database asking for its enforcer PID)