ACL v0.4.0 Acl View Source

Acl

ACL or access control list is a list of permissions attached to a specific object for certain users. This ACL is designed to be used in a phoneix (Elixir) project and handles all your permissions managment. It requires following depedencies

  {:ecto_sql, "~> 3.0"}
  {:jason, "~> 1.0"}
  {:plug_cowboy, "~> 1.0.0"}
  {:ex_doc, ">= 0.0.0", only: :dev}
  {:phoenix, "~> 1.3.0"}
  {:phoenix_pubsub, "~> 1.0"}
  {:phoenix_ecto, "~> 3.2"}
  {:postgrex, ">= 0.0.0"}
  {:phoenix_html, "~> 2.10"}
  {:phoenix_live_reload, "~> 1.0", only: :dev}
  {:gettext, "~> 0.11"}
  {:cowboy, "~> 1.0"}

Installation guide

To add ACL to your project simpley add to your projects depedencies

{:acl, "~> 0.4.0"}

and run "mix deps.get" thn you need to add :acl to your application and also add configuration for :acl in your config file

config :acl, Acl.Repo,
   adapter: Ecto.Adapters.Postgres,
   username: "user",
   password: "pass",
   database: "db",

you also need to run migrations for acl, which creates tables required for the acl, you can find migrations inside acl folder in your deps directory.

ACL guide

it has three essential Componenets Roles,Resources (handles as res), and Rules.

Roles

Roles (users/user groups) are entities you want to give or deny access to. you can add a new role by

Acl.addRole(%{"role" => "role", "parent" => "parent"})

in roles parent is optional and you may choose to provide it or not.

Res

Res are entities you want to give or deny access for. they can be anything real or arbitaray.

you can add a new res by

Acl.addRes(%{"res" => "res", "parent" => "parent"})

in res parent is optional and you may choose to provide it or not.

Rules

Rules are definition for your set of permissions. you can add rule by

addRule(role, res,  permission \1, action \nil ,condition \1 )

and you can check if a role or permission exists by

hasAccess(role, permission \"read", res \nil, action \nil)

valid inputs for permmission are "POST","GET","PUT" ,"DELETE","read","write","delete","edit". permissions have downword flow. i.e if you have defined permissions for a higher operation it automatically assings them permissions for lower operations. like "edit" grants permissions for all operations. their heirarchy is in this order

"read" < "write" < "delete" < "edit"
"GET" < "POST" < "DELETE" < "PUT"

you can use actions argument to define actions for your resources or not use thema t all and skip sending them in arguments. like i have a resource as maps and i can define actions like display/resize etc. now actions can be pages in a web application or can be tables for an api or can be functions inside a controller. you can be as creative as you wish

and last argument condition is to define permission levels (0,1,2,3), and they map in this order.

0 -> "none"
1 -> "self"
2 -> "related"
3 -> "all"

you can add a res with empity string and it will be used as super resource. granting permission to that resource is equivalent to making a superadmin and any role who have access to this resource will have all permissions.

for issues pls open an issue