TOC? =BW Rox rights management=

This page is to gather some ideas on implementation of rights within BW-Rox, to figure out requirements and possible solutions. For now it's pretty empty (just one skype-discussion posted) but I hope to update it soon.

=Requirements=

• Must be flexible and extendable
• Needs to be granular: rights should work both on method level and on object level
• Avoid situation where rights are too broad: rights to edit trips should not mean rights to edit ALL trips
• Avoid rights-levels, as a hierarchy of rights is meaningless in practice
• Implementation needs to be easy to use, like HasRight?(method,scope)
• MUST carry on the current level of documentation and commenting
• MUST be easy to manage on the user-end

=Proposed solutions=

==One object, one right==

Create rights for specific objects. A right refers to one specific object and whoever has that right can use it only on this object.

Syntax would be something like: HasRight?("editNamedBlogEntry")

Pro:

• Very granular
• Extends easily

Con:

• Rights would be complete chaos and we'd be swamped with rights
• Figuring out which rights exists and which don't will become a problem
• Impossible to maintain

==One right, one table==

Create a table per right/method, such as CanEditTripBlog? with columns member_id and trip_id.

Pro:

• Granular

Con:

• Hard to extend effectively
• Hard to maintain
• Messes up database by littering with tables

==MTB rights system==

To come

based on these db tables: mod_user_apps mod_user_auth mod_user_authgroups mod_user_authrights mod_user_grouprights mod_user_implications mod_user_rights

==Abstract rights==

Define rights as rights to do certain things in apps. This could be the right to execute a method in a given app. Make this granular by either allowing for scope(all) or scope(object).

This would be based upon tables like:

• rights
  • id
  • name
  • app
  • method

• members_rights
  • member_id
  • right_id
  • scope

Scope can be a given object (a trips blog) or a more abstract object (a language that one can translate).

Pro:

• Adds granularity
• Easy to extend with more rights

Con:

• Needs to implemented from scratch