I see to add that feature over the weekend @larry. I'm using this role model together with the excellent buddy-auth library.
larry google groups <lawrencecloj...@gmail.com> schrieb am Mi., 12. Okt. 2016 um 19:12 Uhr: > >That would only get 64 states into a 64 bit Long, but was always enough. > > The bitmask idea is good. I agree there are always tradeoffs. A number is > less readable, but more efficient. I would be happy if there was a small > library that did just (roles/permissions), and which I could compose with > my own auth schemes (because I have often been frustrated with the > heaviness of Friend). > > > > > On Tuesday, October 11, 2016 at 10:16:51 AM UTC-4, Torsten Uhlmann wrote: > > Thanks for the comments! > > @larry I was reminded by your comment at how I used to use bitmasks > before, like @adrian commented. > That would only get 64 states into a 64 bit Long, but was always enough. I > have no performance data on prime number sieves but I suspect that would > take longer than checking set bits of a long. > > Anyway, I was thinking about your suggestion, and there might be away to > integrate such a scheme without totally warping the current implementation. > > So, we would still need a definition of all existing permissions, the one > you initialize the library with at the start of your application. That > receives a map with the role keyword and a single or set of permissions. > > Instead of making the role name a keyword we could also allow a number as > key. That number would then be a number by the power of 2 (if using the > bitmask approach). The value is still one or more permissions. > > The user would then be added inside the :roles key a number like 5, which > would indicate the roles 1 and 4 are given. > If the library detects a number instead of a set of roles it would try to > destructure it against the global role map. > > The same with the resource that asks for the permission- it could have a > permission attached or a number. That number would then map against the > roles the same way destructuring was done for the user. > > I acknowledge that using the number would be limiting compared to using > the list of permission strings (because a set bit would represent one role > and not a single permission)- so it's the users obligation to create a sane > set of roles or to create basically a one-to-one relationship between a > number (a role) and a permission. > > Kind Regards, > Torsten. > > <adrian...@mail.yu.edu> schrieb am Di., 11. Okt. 2016 um 14:04 Uhr: > > 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 clo...@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+u...@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+u...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > -- > 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. > -- 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.
