Test dict objects on target rules

[Tiago de Carvalho Miranda]

Hi!
I cant realy understand the way the target is tested against the real value.

After define this rule

{ target: { 'credentials.roles.recruiter': undefined },
  effect: 'deny'
},
{ effect: 'permit' }

I expect that

{ credentials: {
      roles: {
          recruiter: {}
      }
  }
}

Would resolve to credentials.roles.recruiter = "Object" (or something not undefined)
And the rule would deny the access.

Why is my rule denying the access to that case?

[Tiago de Carvalho Miranda]

I am really missing something here..

I expect that this policy:

 plugins: {  
     rbac: (request, callback) => callback(null, {
         apply: 'permit-overrides',
         rules: [
             { target: { 'credentials.roles.job_admin': request.params.job },
               effect: 'permit'
             },
             { effect: 'deny' }
         ]
     })
 }

Would permit a request to /job/{2}
If my credentials are:

 { _id: '...',
   roles: {
       job_admin: [ '2' ]
   }
 }

Where am I missing?
thanks!

[Francisco Gouveia]

Hi @TCMiranda.

At the moment, the plugin doesn't evaluate nested properties.

But, it seems to me that this is not the only reason you're not being successful.

Let's see...

{ target: { 'credentials.roles.recruiter': undefined },
  effect: 'deny'
},
{ effect: 'permit' }

I believe that what you are trying to match is the role of the user with the word recruiter.

This is how I would do it:

{ target: { 'credentials:roles': 'recruiter' },
  effect: 'deny'
},
{ effect: 'permit' }

With this rules, if the user has the following credentials object:

{
   _id: ...,
   roles: ['recruiter'],
   ...
}

then the rule with effect: deny would be applied, having the access to the route denied (because that's the effect of that specific rule).

If you see the API reference, at the end of the target section, you will see that you can match targets with properties from different sources. One of them is credentials. This credentials object is internally obtained from request.auth.credentials. As it is there also documented, to specify the source, you prefix the property as follows:

source:property

As you see, I use : between the source and the property. In your example, you are using ..

---

In your other example you are doing:

'credentials.roles.job_admin': request.params.job

You are matching a role with a parameter that you receive. This means that you are matching one value from one source (credentials) with a value from another source (params). It is an interesting idea and would be great to have in a future version. For now, the targets are limited to static value matching.

---

I will create two issues with the missing features that you find out. I just don't know how soon I will be able to look into it.

[Francisco Gouveia]

Created issues. Closing this one

[Tiago de Carvalho Miranda]

@franciscogouveia thank you for the answer!

Yes, it seems that I had more than one issue!

About nested structures

First, I really think that it would be great to use dot notation, as it is an usual way to express nested access.

I cant just use

{
  _id: ..,
  roles: [
    'recruiter'
  ]
}

Because I may define a role like

{
  _id: ..,
  roles: {
    job_admin : [
      'job_id'
    ]
  }
}

About : separator

Yes, I really assumed that the . would separate source and property.
If dot notation is used, wouldn't it make a little more sense to keep . to access the source?

Thinking about the Hapi structure, to fix the "source" on the hapi request object wouldn't be a bad idea.

About custom sources

Thats the only thing I didn't understand.

I followed: https://github.com/franciscogouveia/hapi-rbac/blob/master/API.md#target-matching
Defining the route plugins.rbac as a callback function.

Is the value returned from the callback used to statically define the policy? Or it is executed every time a request matches? (which is what I understood)

Ok! Thats it! I may fork it, since I have a real need to adopt a well defined rule based access control module on a project.

This one fits perfectly, if not by those points.

Do you agree with all my points? Would you agree to implement those features in hapi-rbac package in a short term?

Of couse it would be a major....

Thanks!!