If you wanted to do something more efficient, why not just use a bitmask? That is far more efficient than prime factorization.
On Tuesday, October 11, 2016 at 12:06:19 AM UTC-4, larry google groups wrote: > > 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.