Re: [ANN] permissions - role & permission based access control
@larry I added bitmask permissions to https://github.com/tuhlmann/permissions together with a set of unit tests and a description in Readme. Please have a look if you like. I don't think I will ever use it as I'm quiet content with the literal approach. But it was an interesting exercise to separate concerns in order to make the library more flexible and not more complex at the same time. Kind Regards, Torsten. schrieb am Do., 13. Okt. 2016 um 14:50 Uhr: > My suggestion of a bitmask was just a response to a suggestion of prime > factorization for encoding roles in an integer. I think using a set is just > fine. The space requirements for a small set of keywords is negligible in > the larger scheme of things. It also permits more readable code (always a > good thing) with bits of code that need to interact with it. > > > On Thursday, October 13, 2016 at 7:56:10 AM UTC-4, Torsten Uhlmann wrote: > > It might be premature optimization, or you could view it as a different > approach, for a different usage scenario. > I'm myself pretty content with the literal approach, we're using this in a > fairly large application and haven't experienced any problems with regards > of performance or amount of data attached to users so far. > > On the other hand I see these suggestions as a way to experiment with > alternative approaches, which might as well teach me something... > > Stefan Kamphausen schrieb am Do., 13. Okt. 2016 um > 10:29 Uhr: > > Hi, > > Doesn't that feel like premature optimization to you, too? Bitmasks are > much harder to read than sets with spelled out roles and I wonder if the > performance gain is really worth that. And it poses a limit of 64 roles. I > have seen several enterprise applications that had far more than 64 roles > and/or permissions. > > Or am I missing something here? > > Just my 2ct. > > Kind regards, > Stefan > > -- > 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.
Re: [ANN] permissions - role & permission based access control
My suggestion of a bitmask was just a response to a suggestion of prime factorization for encoding roles in an integer. I think using a set is just fine. The space requirements for a small set of keywords is negligible in the larger scheme of things. It also permits more readable code (always a good thing) with bits of code that need to interact with it. On Thursday, October 13, 2016 at 7:56:10 AM UTC-4, Torsten Uhlmann wrote: > > It might be premature optimization, or you could view it as a different > approach, for a different usage scenario. > I'm myself pretty content with the literal approach, we're using this in a > fairly large application and haven't experienced any problems with regards > of performance or amount of data attached to users so far. > > On the other hand I see these suggestions as a way to experiment with > alternative approaches, which might as well teach me something... > > Stefan Kamphausen > schrieb am Do., 13. > Okt. 2016 um 10:29 Uhr: > >> Hi, >> >> Doesn't that feel like premature optimization to you, too? Bitmasks are >> much harder to read than sets with spelled out roles and I wonder if the >> performance gain is really worth that. And it poses a limit of 64 roles. I >> have seen several enterprise applications that had far more than 64 roles >> and/or permissions. >> >> Or am I missing something here? >> >> Just my 2ct. >> >> Kind regards, >> Stefan >> >> -- >> 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.
Re: [ANN] permissions - role & permission based access control
It might be premature optimization, or you could view it as a different approach, for a different usage scenario. I'm myself pretty content with the literal approach, we're using this in a fairly large application and haven't experienced any problems with regards of performance or amount of data attached to users so far. On the other hand I see these suggestions as a way to experiment with alternative approaches, which might as well teach me something... Stefan Kamphausen schrieb am Do., 13. Okt. 2016 um 10:29 Uhr: > Hi, > > Doesn't that feel like premature optimization to you, too? Bitmasks are > much harder to read than sets with spelled out roles and I wonder if the > performance gain is really worth that. And it poses a limit of 64 roles. I > have seen several enterprise applications that had far more than 64 roles > and/or permissions. > > Or am I missing something here? > > Just my 2ct. > > Kind regards, > Stefan > > -- > 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.
Re: [ANN] permissions - role & permission based access control
Hi, Doesn't that feel like premature optimization to you, too? Bitmasks are much harder to read than sets with spelled out roles and I wonder if the performance gain is really worth that. And it poses a limit of 64 roles. I have seen several enterprise applications that had far more than 64 roles and/or permissions. Or am I missing something here? Just my 2ct. Kind regards, Stefan -- 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.
Re: [ANN] permissions - role & permission based access control
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 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. > > 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 > o
Re: [ANN] permissions - role & permission based access control
>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. > > > 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
Re: [ANN] permissions - role & permission based access control
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.
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 r
Re: [ANN] permissions - role & permission based access control
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
--
Re: [ANN] permissions - role & permission based access control
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.
