feat(defaultrolemanager.ts): add hierarchical domain support for rbac

[Sefriol]

Work in progress. Initial idea from https://github.com/casbin/casbin/pull/1040

• [x] add basic functionality to the roleManager
• [x] Fix related helper functions
• [ ] Add documentation?
• [x] Rebase from master when https://github.com/casbin/node-casbin/pull/378 merged

g2 defitions are in "reverse" order for reason. Other way around it would not work.

Discussion welcome.

[casbin-bot]

@nodece @Zxilly @Shivansh-yadav13 please review

[CLAassistant]

All committers have signed the CLA.

[hsluoyz]

@Sefriol plz fix:

[Sefriol]

Helper functions are now fixed and branch is rebased. What kind of documentation would you want @hsluoyz?

EDIT: Opinions about the testing set would be nice. Do we need more complicated test cases?

[hsluoyz]

@Sefriol good work! Plz add docs to v2 docs: https://casbin.io/docs/rbac-with-domains

[hsluoyz]

@Sefriol plz fix:

[Sefriol]

I changed tests to use csv and conf files instead of programmatically generating the model.

[nodece]

Thank @Sefriol for your contribution! Your approach is a good idea, but we have already added many magic methods to RoleManager, I think we should be able to extend the g() method, and pass a method/const to g() to support this feature like g(r.sub, p.sub, r.dom, inject("g2")), we will inject the roleManger of g2 to g(), then we check whether thearg includes the inject().

const name = "built-in-role-manager";
function inject(arg: string) {
  switch (arg) {
    case "g2":
      return {
        name:  name,
        value: rm2
      };
  }
}

function generateGFunction(rm: rbac.RoleManager): any {
  return async function (...args: any[]): Promise<boolean> {
    const g2 = args[args.length - 1];
    if (Object.prototype.toString.call(g2) === '[object Object]') {
      if (g2.name === builtInRoleManager) {
        // link the g2.value to the root role manager to build a new role link, then check the link
      }
    }
  };
}

What do you think about this approach? Please let me know if you have any ideas.

[Sefriol]

I definitely would prefer a solution where hierarchy is defined by the model itself instead of requiring different calls on the RoleManager to setup the hierarchy.

Current test cases cover pretty much what I try to achieve. So minor details are not as important as others, but the test I have created deliver the perfect authorization solution for my use case. Not sure about the performance. I would ofcourse want a solution which is as elegant as possible while delivering the core functionality that I desire.

[Sefriol]

@nodece Any update on the idea you proposed?

[nodece]

I definitely would prefer a solution where hierarchy is defined by the model itself instead of requiring different calls on the RoleManager to setup the hierarchy.

I agreed with @Sefriol, it looks more standard.

What do you think of it? @hsluoyz

[hsluoyz]

lgtm, merged, plz add the docs

[github-actions[bot]]

:tada: This PR is included in version 5.20.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[Sefriol]

@nodece @hsluoyz You decided that this is a better option?

I was wondering since https://github.com/casbin/casbin/pull/1040 has not moved at all.

@sujit-baniya also raised some questions in the pull request, which might indicate that there is a problem with the implementation.

This was just an idea on how the implementation could be done, but @nodece idea could have been even better?

Just to confirm: Is this now the way how hierarchy will be defined in all casbin projects?