/users/:id/account not accessible about loopback-example-access-control HOT 14 CLOSED

Hi,

I debugged the issue. It seems that we pick the ‘DENY’ rule from the following acls:

{
"accessType": "",
"permission": "DENY",
"principalType": "ROLE",
"principalId": "$everyone"
},
{
"accessType": "",
"permission": "ALLOW",
"principalType": "ROLE",
"principalId": "$owner"
},
..
}

The algorithm we have try to weigh the matching rules. In this case, the ‘DENY’ one has higher score over the ‘ALLOW’ one. Intuitively, the ‘$owner’ role is more specific than the ‘$everyone’. I wonder if we should change the current algorithm to match it.

Thanks,

Raymond Feng
Co-Founder and Architect @ StrongLoop, Inc.

StrongLoop makes it easy to develop APIs in Node, plus get DevOps capabilities like monitoring, debugging and clustering.

On Mar 18, 2014, at 5:49 PM, Nico Prananta [email protected] wrote:

Hi,

I'm trying to wrap my head around loopback's ACL but I couldn't figure out why /users/:id/account is not accessible even when logged in user calls it. Keeps getting access denied.

/accounts/:id?access_token= also got access denied.

I thought since user belongs to account and account has acl:

{
"accessType": "*",
"permission": "ALLOW",
"principalType": "ROLE",
"principalId": "$owner"
}

account can be accessed by the owner which is the user it is associated with.

Enlighten me, please

—
Reply to this email directly or view it on GitHub.

from loopback-example-access-control.

So how do you propose the solution to allow owner and deny everyone else?

from loopback-example-access-control.

I'll investigate the possibility to consider the roles to determine while rule is more specific. For example, say '$everyone' is wider that '$owner', then the rule for '$owner' will take precedence.

from loopback-example-access-control.

@raymondfeng is this good to close?

from loopback-example-access-control.

What is the status of this issue please? It appears that the original behavior stated above ("It seems that we pick the ‘DENY’ rule from the following acls") is still in force. Thanks.

from loopback-example-access-control.

If the issue has in fact been addressed, does any sample project exist?

What I would expect, would be that a user logged in would be able to 'find' only those model instances (records) that she created, and not any others. However the user 'finds' ALL records, even though she did not create. Am I not understanding the semantics of the $owner role?

Googleing, I found that it is necessary to create a 'belongsTo' relation, and explicitly create a property which serves as the foreignKey. When an instance is created, is the id of the 'owner' inserted as the foreign key automatically, or must the creator set that explicitly? I've tried the latter, with the following results... (Thanks in advance)

{
"name": "casinoUser",
"base": "User",
"strict": false,
"idInjection": true,
"options": {
"validateUpsert": true
},
"properties": {
"firstName": {
"type": "string",
"required": true
},
"lastName": {
"type": "string",
"required": true
},
"casinoId": {
"type": "string",
"required": true
},
"ownerId": {
"type": "string",
"required": true
}
},
"validations": [],
"relations": {
"casino": {
"type": "belongsTo",
"model": "casino",
"foreignKey": "casinoId"
},
"user": {
"type": "belongsTo",
"model": "User",
"roles": ["owner"],
"foreignKey": "ownerId"
}
},
"acls": [
{
"accessType": "",
"principalType": "ROLE",
"principalId": "$everyone",
"permission": "DENY"
},
{
"accessType": "",
"principalType": "ROLE",
"principalId": "admin",
"permission": "ALLOW"
},
{
"accessType": "*",
"principalType": "ROLE",
"principalId": "$owner",
"permission": "ALLOW"
}
],
"methods": {}
}

loopback:security:role isInRole(): $everyone +24s
loopback:security:access-context ---AccessContext--- +1ms
loopback:security:access-context principals: +1ms
loopback:security:access-context principal: {"type":"USER","id":"55fa0f3e2fe396f3155d9a0e"} +1ms
loopback:security:access-context modelName casinoUser +1ms
loopback:security:access-context modelId undefined +1ms
loopback:security:access-context property find +2ms
loopback:security:access-context method find +1ms
loopback:security:access-context accessType READ +4ms
loopback:security:access-context accessToken: +1ms
loopback:security:access-context id "LaghUTG5gOBYr4eOD7B6zxJxnIGElg3wzjmZLT2coFlrIg5UdMnmxppUwGT8i415" +0ms
loopback:security:access-context ttl 1209600 +1ms
loopback:security:access-context getUserId() 55fa0f3e2fe396f3155d9a0e +1ms
loopback:security:access-context isAuthenticated() true +1ms
loopback:security:role Custom resolver found for role $everyone +1ms
loopback:security:role isInRole(): $everyone +1ms
loopback:security:access-context ---AccessContext--- +1ms
loopback:security:access-context principals: +1ms
loopback:security:access-context principal: {"type":"USER","id":"55fa0f3e2fe396f3155d9a0e"} +0ms
loopback:security:access-context modelName casinoUser +1ms
loopback:security:access-context modelId undefined +0ms
loopback:security:access-context property find +1ms
loopback:security:access-context method find +0ms
loopback:security:access-context accessType READ +0ms
loopback:security:access-context accessToken: +1ms
loopback:security:access-context id "LaghUTG5gOBYr4eOD7B6zxJxnIGElg3wzjmZLT2coFlrIg5UdMnmxppUwGT8i415" +0ms
loopback:security:access-context ttl 1209600 +0ms
loopback:security:access-context getUserId() 55fa0f3e2fe396f3155d9a0e +0ms
loopback:security:access-context isAuthenticated() true +0ms
loopback:security:role Custom resolver found for role $everyone +1ms
loopback:security:role isInRole(): admin +0ms
loopback:security:access-context ---AccessContext--- +0ms
loopback:security:access-context principals: +1ms
loopback:security:access-context principal: {"type":"USER","id":"55fa0f3e2fe396f3155d9a0e"} +0ms
loopback:security:access-context modelName casinoUser +0ms
loopback:security:access-context modelId undefined +0ms
loopback:security:access-context property find +0ms
loopback:security:access-context method find +0ms
loopback:security:access-context accessType READ +0ms
loopback:security:access-context accessToken: +0ms
loopback:security:access-context id "LaghUTG5gOBYr4eOD7B6zxJxnIGElg3wzjmZLT2coFlrIg5UdMnmxppUwGT8i415" +0ms
loopback:security:access-context ttl 1209600 +0ms
loopback:security:access-context getUserId() 55fa0f3e2fe396f3155d9a0e +0ms
loopback:security:access-context isAuthenticated() true +0ms
loopback:security:role Custom resolver found for role admin +0ms
loopback:security:role isInRole(): $owner +0ms
loopback:security:access-context ---AccessContext--- +1ms
loopback:security:access-context principals: +0ms
loopback:security:access-context principal: {"type":"USER","id":"55fa0f3e2fe396f3155d9a0e"} +0ms
loopback:security:access-context modelName casinoUser +0ms
loopback:security:access-context modelId undefined +0ms
loopback:security:access-context property find +0ms
loopback:security:access-context method find +0ms
loopback:security:access-context accessType READ +0ms
loopback:security:access-context accessToken: +0ms
loopback:security:access-context id "LaghUTG5gOBYr4eOD7B6zxJxnIGElg3wzjmZLT2coFlrIg5UdMnmxppUwGT8i415" +0ms
loopback:security:access-context ttl 1209600 +0ms
loopback:security:access-context getUserId() 55fa0f3e2fe396f3155d9a0e +0ms
loopback:security:access-context isAuthenticated() true +0ms
loopback:security:role Custom resolver found for role $owner +0ms
loopback:security:acl The following ACLs were searched: +1ms
loopback:security:acl ---ACL--- +1ms
loopback:security:acl model casinoUser +0ms
loopback:security:acl property * +0ms
loopback:security:acl principalType ROLE +0ms
loopback:security:acl principalId admin +0ms
loopback:security:acl accessType * +0ms
loopback:security:acl permission ALLOW +0ms
loopback:security:acl with score: +0ms 7508
loopback:security:acl ---ACL--- +0ms
loopback:security:acl model casinoUser +0ms
loopback:security:acl property * +0ms
loopback:security:acl principalType ROLE +1ms
loopback:security:acl principalId $everyone +0ms
loopback:security:acl accessType * +0ms
loopback:security:acl permission DENY +0ms
loopback:security:acl with score: +0ms 7495
loopback:security:acl ---ACL--- +0ms
loopback:security:acl model casinoUser +0ms
loopback:security:acl property * +0ms
loopback:security:acl principalType ROLE +0ms
loopback:security:acl principalId $everyone +0ms
loopback:security:acl accessType * +0ms
loopback:security:acl permission DENY +0ms
loopback:security:acl with score: +0ms 7495
loopback:security:acl ---Resolved--- +0ms
loopback:security:access-context ---AccessRequest--- +0ms
loopback:security:access-context model casinoUser +1ms
loopback:security:access-context property find +0ms
loopback:security:access-context accessType READ +0ms
loopback:security:access-context permission ALLOW +0ms
loopback:security:access-context isWildcard() false +0ms
loopback:security:access-context isAllowed() true +0ms

from loopback-example-access-control.

This does not solve the problem. After updating this and also grating all the things to acl for user model thats extend from User Model, I still get 401 : AUTHORIZATION_REQUIRED", "stack": "Error: Authorization in normal /get calls for user.

from loopback-example-access-control.

same problem.

from loopback-example-access-control.

@raymondfeng What's the status on this issue?

from loopback-example-access-control.

@richardpringle Can you try to reproduce this issue and see if it's still relevant?

from loopback-example-access-control.

@superkhau, it's still relevant, I put a bug label on the issue

from loopback-example-access-control.

Cool, I'll assume you got it then.

from loopback-example-access-control.

@nicnocquee , @ryncorbeil-ssf , and @vabnirvana, I took a deeper look into this issue and it turns out that the functionality of the example is exactly as expected.
The acl,

 {
   "accessType": "*",
   "principalType": "ROLE",
   "principalId": "$everyone",
   "permission": "DENY"
 }

puts a blanket deny on every api endpoint. Each of the other ACLs give specific ROLE access to the following endpoints:

projects/listProjects
projects/
projects/{id}
projects/donate
projects/withdraw

with the respective properties:

listProjects
find
findById
donate
withdraw

Any other endpoints will not work, for example projects/{id}/user.

So, I am going to close the issue. If you have any additional questions please post them here. See https://github.com/strongloop/loopback/wiki/Questions for more details on posting questions.

from loopback-example-access-control.

@ryncorbeil-ssf, I am not quite clear on what your question is.
I believe that the foreign automatically inserted if it is not explicitly declared (see BelongsTo+relations docs).

As for your specific case, it is not quite clear what you are trying to accomplish. I think the best place for you to get your question answered is at https://groups.google.com/forum/#!forum/loopbackjs.

please read the questions wiki for more info to find the best way to get your questions answered.

Also, instead of posting code along with the console output, it's easier for someone to reproduce your issue with an actual repo, checkout the bug-report section of the wiki.

Good luck!

from loopback-example-access-control.