A minor pet peeve of mine, but is it possible to attach prime numbers to 
the roles, and to then decipher the roles from the factors of the total? 
Using strings or keywords for permissions often strikes me as inefficient. 
Assuming:

create -- 2

read -- 3

update  -- 5

delete -- 7

bulk-erase -- 11

delete-others -- 13

So given a permissions value of 330, we can factor 330 and find 2, 3, 5 and 
11. And it seems more efficient (though less readable) to carry around 
"330" rather than [:create :read :update :bulk-erase]

I would very much like to see a small library that does this for me, rather 
than always writing this code for myself. 









On Monday, October 10, 2016 at 6:51:14 AM UTC-4, Torsten Uhlmann wrote:
>
> I'd like to announce the first preview of "permissions"- a small library 
> to handle role and permission based access control in web applications.
>
> Github: https://github.com/tuhlmann/permissions
> Clojars: https://clojars.org/agynamix/permissions
>
> Permissions is heavily inspired and modeled after Apache Shiro's 
> WildcardPermission: http://shiro.apache.org/permissions.html.
>
> In a nutshell, you can define permissions based on a 
>
> - domain: "users", "company", "admin", whatever the main areas of your 
> application might be, 
> - actions: "read", "edit", "delete", "upload" or however you like to name 
> them,
> - entities: "abcd1234", to limit access only to a resource with this 
> specific ID
>
> And you have the wildcard. You can grant access to all domains, all 
> actions, all entities by applying the wildcard in the appropriate field.
>
> Examples:
>
> "*" would grant access to everything (internally this would be represented 
> as "*:*:*", a wildcard for each
> "users:*" would grant the user that holds the permission to everything 
> that asks for a "users" permission
> "users:read" would grant the user read access
> "users:write:abcd1234" would grant write access to that specific resource
>
> Roles:
>
> The library also holds an implementation for roles and an easy to use API 
> to check if a given user holds a permission or does not.
>
> Roles are really just a container for a set of permissions. In order for 
> the library to know which roles exist it has to be initialized with a map 
> of roles.
> The key is the name of the role, the value is a set of permissions. Such a 
> definition could look like:
>
> (def roles {:user/admin "user/*"
>             :user/all   #{"user/read" "user/write"}
>             :admin/all  "*"
>             :company/super #{"company/read" "company/write" "company/edit" 
> "company/delete"}
>             }
>
>
> In order to let the library check if a user "has-permission?" or 
> "lacks-permission?" it expects a key ":roles" and/ or a key ":permissions" 
> (you can override that default) inside the user map.
>
> (def user {:roles #{:user/all :company/super}
>            :permissions #{"library/read" "company/gibberish"}
>            ... lots of other keys
>            }
>
>
> It would take the roles, flatten them to a list of permissions (through 
> that mapping you initialized it with, remember?) and add the individual 
> permissions to them.
> It would then check if the permission required by the resource the user is 
> trying to access is covered by one of the permissions of the user. How you 
> handle granted or denied access is totally up to you.
>
> I have used this role based access management in a number of different 
> Scala projects (https://github.com/liftmodules/mapperauth, 
> https://github.com/eltimn/lift-mongoauth) and found it quiet versatile. 
> I'm using it now in a ClojureScript project and thought that might 
> actually be a good candidate for a standalone library. Now here it is.
>
> If you're interested in it please have a look at the tests and the code- 
> I'm sure there is much room for improvement and interesting ideas I haven't 
> thought about.
> One thing that especially bugs me is the need to initialize the map of 
> existing roles prior to using the library. If you come up with a better way 
> I'm eager to hear it.
>
> Please keep in mind that the code is merely a preview at the moment. 
> Changes to the API should comes as no surprise.
>
> Thanks,
> Torsten.
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to