Error "401 Authorization required" when querying methods involving relations #426

sam-artuso · 2014-07-31T20:28:34Z

I've recently migrated an application to LoopBack 2.0.

All my models require user authentication and have these ACLs:

    "acls": [
      {
        "accessType": "*",
        "permission": "DENY",
        "principalType": "ROLE",
        "principalId": "$everyone"
      },
      {
        "accessType": "READ",
        "permission": "ALLOW",
        "principalType": "ROLE",
        "principalId": "$authenticated"
      }
    ]

I have a model called issues. After logging in through the POST method /Users/login:

I don't have any problems when calling the GET method /issues. I get a list of issues as expected;
When I query a method involving a relation between two models (e.g. GET /issues/{id}/categories), I get the error 401 Authorization required. The same model used to work in Loopback 1.0.

Any clues?

The text was updated successfully, but these errors were encountered:

daankets · 2014-08-12T12:56:13Z

I have the same issue. I also think the 401 Unauthorized is a wrong response. I am authenticated, so it should be 403 forbidden. I'm opening a new issue for that.

gcirne · 2014-08-12T13:01:31Z

I think this has already been implemented: #301

daankets · 2014-08-12T14:01:59Z

This issue (#426) itself is not yet resolved. Defining an ACL on a relation property does not seem to work for me.
Replicate by defining a model, adding a relationship to it (for example many user to many group). Then DENY ALL on * for ROLE $everyone, and finally ALLOW READ/EXECUTE on for ROLE $authenticated. I consequently get access denied for these relationships.

dagumak · 2014-08-19T14:00:17Z

I am having the exact same issue! I spent a few hours digging through anything I can find, but I still couldnt get it to work!

fabien · 2014-08-19T14:07:45Z

@dagumak - can you post the ACL's you defined?

dagumak · 2014-08-19T14:12:09Z

@fabien I posted it here (#459 (comment)), but here it is:

{
  "name": "TestUser",
  "base": "User",
  "strict": true,
  "properties": {
    "username": {
      "type": "string",
      "required": true
    }
  },
  "validations": [],
  "relations": {
    "message": {
      "type": "hasMany",
      "model": "Message",
      "foreignKey": "userId"
    }  
  },
  "acls": [

  ],
  "methods": []
}


{
  "name": "Message",
  "base": "PersistedModel",
  "properties": {
    "type": {
      "type": "string",
      "required": true
    },
    "text": {
      "type": "string",
      "required": true
    }
  },
  "validations": [],
  "relations": {
    "testUser": {
      "type": "belongsTo",
      "model": "TestUser",
      "foreignKey": "userId"
    }
  },
  "acls": [
    {
      "principalType": "ROLE",
      "principalId": "$everyone",
      "permission": "ALLOW"
    }
  ],
  "methods": []
}

fabien · 2014-08-19T14:30:59Z

I think the core User ACL's are interfering with the ACL's you defined. I recall the following from one of my projects, which overrides all the ACL's:

TestUser.settings.acls = [ 
      { principalType: 'ROLE',
        principalId: '$everyone',
        permission: 'DENY' },
      { principalType: 'ROLE', // this is the important bit
        principalId: '$owner',
        permission: 'ALLOW' },
      { principalType: 'ROLE',
        principalId: '$everyone',
        permission: 'ALLOW',
        property: 'create' },
      { principalType: 'ROLE',
        principalId: '$owner',
        permission: 'ALLOW',
        property: 'deleteById' },
      { principalType: 'ROLE',
        principalId: '$everyone',
        permission: 'ALLOW',
        property: 'login' },
      { principalType: 'ROLE',
        principalId: '$everyone',
        permission: 'ALLOW',
        property: 'logout' },
      { principalType: 'ROLE',
        principalId: '$owner',
        permission: 'ALLOW',
        property: 'findById' },
      { principalType: 'ROLE',
        principalId: '$owner',
        permission: 'ALLOW',
        property: 'updateAttributes' },
      { principalType: 'ROLE',
        principalId: '$everyone',
        permission: 'ALLOW',
        property: 'confirm' }
    ]

fabien · 2014-08-19T14:32:12Z

@dagumak the very least you could do is trace your current TestUser.settings.acls to compare them.

dagumak · 2014-08-19T14:35:49Z

@fabien I feel silly for asking, but other than console log, how can I do that?

On Tue, Aug 19, 2014 at 11:32 PM, Fabien Franzen notifications@github.com
wrote:

@dagumak the very least you could do is trace your current TestUser.settings.acls to compare them.

Reply to this email directly or view it on GitHub:
#426 (comment)

fabien · 2014-08-19T14:46:52Z

@dagumak console.log is fine

dagumak · 2014-08-19T15:18:16Z

@fabien I am not very familiar with the framework yet, but where are the models loaded and a good place for me to console.log it?

fabien · 2014-08-19T15:29:10Z

You can put the following into a file at /server/boot/debug.js:

module.exports = function(app) {
  var TestUser = app.loopback.getModel('TestUser');
  console.log(TestUser.settings.acls);
};

raymondfeng · 2014-08-19T15:53:26Z

You can run the application with DEBUG enabled:

$ DEBUG=loopback:security:* node .

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 Aug 19, 2014, at 8:29 AM, Fabien Franzen notifications@github.com wrote:

You can put the following into a file at /server/boot/debug.js:

module.exports = function(app) {
var TestUser = app.loopback.getModel('TestUser');
console.log(TestUser.settings.acls);
};
—
Reply to this email directly or view it on GitHub.

dagumak · 2014-08-19T16:08:28Z

@fabien Thanks a bunch! Here it is:

[ { principalType: 'ROLE',
    principalId: '$everyone',
    permission: 'DENY' },
  { principalType: 'ROLE',
    principalId: '$everyone',
    permission: 'ALLOW',
    property: 'create' },
  { principalType: 'ROLE',
    principalId: '$owner',
    permission: 'ALLOW',
    property: 'deleteById' },
  { principalType: 'ROLE',
    principalId: '$everyone',
    permission: 'ALLOW',
    property: 'login' },
  { principalType: 'ROLE',
    principalId: '$everyone',
    permission: 'ALLOW',
    property: 'logout' },
  { principalType: 'ROLE',
    principalId: '$owner',
    permission: 'ALLOW',
    property: 'findById' },
  { principalType: 'ROLE',
    principalId: '$owner',
    permission: 'ALLOW',
    property: 'updateAttributes' },
  { principalType: 'ROLE',
    principalId: '$everyone',
    permission: 'ALLOW',
    property: 'confirm' } ]

SwadhyayStudios · 2015-01-31T18:26:26Z

Is this resolved ? I am still having the same issue
The last thread doesn't help

SwadhyayStudios · 2015-01-31T18:41:17Z

[ { principalType: 'ROLE',
principalId: '$everyone',
permission: 'DENY' },
{ principalType: 'ROLE',
principalId: '$everyone',
permission: 'ALLOW',
property: 'create' },
{ principalType: 'ROLE',
principalId: '$owner',
permission: 'ALLOW',
property: 'deleteById' },
{ principalType: 'ROLE',
principalId: '$everyone',
permission: 'ALLOW',
property: 'login' },
{ principalType: 'ROLE',
principalId: '$everyone',
permission: 'ALLOW',
property: 'logout' },
{ principalType: 'ROLE',
principalId: '$owner',
permission: 'ALLOW',
property: 'findById' },
{ principalType: 'ROLE',
principalId: '$owner',
permission: 'ALLOW',
property: 'updateAttributes' },
{ principalType: 'ROLE',
principalId: '$everyone',
permission: 'ALLOW',
property: 'confirm' },
{ principalType: 'ROLE',
principalId: '$everyone',
permission: 'ALLOW',
property: 'resetPassword',
accessType: 'EXECUTE' },
{ accessType: '*',
principalType: 'ROLE',
principalId: '$everyone',
permission: 'ALLOW' } ]

rubentorresbonet · 2015-02-07T13:16:28Z

Something that helped me with ACL and relations is to run "DEBUG=loopback:security:* slc run" and then check the property it is trying to access.
At first I tried adding ACL to the "orders" property (since it was like /users/2/orders) but it seems like the ACL resolver tried to access this property: __get__orders.
I set that in my json acl file and it is working like a charm.

Example:
"acls": [
{
"accessType": "EXECUTE",
"principalType": "ROLE",
"principalId": "$owner",
"permission": "ALLOW",
"property": "__get__orders"
}

superkhau · 2015-02-26T05:08:35Z

Please create a test project on Github to reproduce the issue as per https://github.com/strongloop/loopback/wiki/Issues#bug-report

LetsDoIt- · 2015-02-26T06:07:27Z

@rubentorresbonet the acl that you defined with the property __get__orders is for which model?
Is it for the user model or for the orders model?

rubentorresbonet · 2015-02-26T07:59:28Z

@LetsDoIt- Have a look here: http://docs.strongloop.com/display/public/LB/Restricting+access+to+related+models

jdhiro · 2015-08-02T21:17:30Z

@rubentorresbonet Holy cow, that worked! I had to use the property __get__customer for a relationship named customer. Thanks!

DEBUG=loopback:security:* slc run really helped me understand what was happening with the ACLs.

This was on a subclassed user model. The full thing looks like this now:

{
  "name": "user",
  "base": "User",
  "idInjection": true,
  "properties": {},
  "validations": [],
  "relations": {
    "customer": {
      "type": "hasOne",
      "model": "Customer"
    }
  },
  "acls": [
    {
      "principalType": "ROLE",
      "principalId": "$owner",
      "permission": "ALLOW",
      "property": "__get__customer"
    }
  ],
  "methods": []
}

This can't possibly be the intended design.

csvan · 2015-09-10T07:09:44Z

Agree with @jdhiro that from a design perspective, this is very uncomfortable. Would it not be better to introduce a single declaration in order to to set R/W/X privileges on a single relation, just as we can do for other built-in methods?

csvan · 2015-09-10T07:10:30Z

By the way, the link to the documentation for accessing related models provided above is broken, the correct one is here:

https://docs.strongloop.com/display/public/LB/Accessing+related+models

mike-aungsan · 2015-10-23T01:28:52Z

I spent a few hours on this too. Doc is not clear. It should clearly mention that default is denied

superkhau · 2015-10-23T02:14:59Z

@crandmck ^

vnathalye · 2015-10-23T11:07:07Z

While trying CoffeeShop example given at https://docs.strongloop.com/display/LB/Getting+started+part+II I'm getting 401 only while editing the review. I've the ACLs defined as given @ https://docs.strongloop.com/display/public/LB/Define+access+controls

So the following ACL entry is failing:

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

If I change $owner to $authenticated, then I don't get 401. So there seems to be some problem in isOwner().
I've tried using DEBUG=loopback:security:* and it gives following output

loopback:security:access-context ---AccessContext--- +1ms
loopback:security:access-context principals: +3ms
loopback:security:access-context principal: {"type":"USER","id":"562a105037cfea381ac14fbb"} +2ms
loopback:security:access-context modelName Review +3ms
loopback:security:access-context modelId 562a105037cfea381ac14fbe +1ms
loopback:security:access-context property upsert +1ms
loopback:security:access-context method upsert +2ms
loopback:security:access-context accessType WRITE +1ms
loopback:security:access-context accessToken: +2ms
loopback:security:access-context id "EoEwOGWIWLNfw4DLgxf9ga2zCoFht974DgCccMFkQLmLrmnQJ64eHJidDIf4e8dh" +1ms
loopback:security:access-context ttl 1209600 +3ms
loopback:security:access-context getUserId() 562a105037cfea381ac14fbb +2ms
loopback:security:access-context isAuthenticated() true +3ms
loopback:security:role Custom resolver found for role $everyone +0ms
loopback:security:role isInRole(): $everyone +2ms
loopback:security:access-context ---AccessContext--- +1ms
loopback:security:access-context principals: +1ms
loopback:security:access-context principal: {"type":"USER","id":"562a105037cfea381ac14fbb"} +1ms
loopback:security:access-context modelName Review +2ms
loopback:security:access-context modelId 562a105037cfea381ac14fbe +1ms
loopback:security:access-context property upsert +1ms
loopback:security:access-context method upsert +3ms
loopback:security:access-context accessType WRITE +1ms
loopback:security:access-context accessToken: +1ms
loopback:security:access-context id "EoEwOGWIWLNfw4DLgxf9ga2zCoFht974DgCccMFkQLmLrmnQJ64eHJidDIf4e8dh" +2ms
loopback:security:access-context ttl 1209600 +2ms
loopback:security:access-context getUserId() 562a105037cfea381ac14fbb +2ms
loopback:security:access-context isAuthenticated() true +1ms
loopback:security:role Custom resolver found for role $everyone +1ms
loopback:security:role isInRole(): $owner +2ms
loopback:security:access-context ---AccessContext--- +1ms
loopback:security:access-context principals: +2ms
loopback:security:access-context principal: {"type":"USER","id":"562a105037cfea381ac14fbb"} +2ms
loopback:security:access-context modelName Review +2ms
loopback:security:access-context modelId 562a105037cfea381ac14fbe +2ms
loopback:security:access-context property upsert +1ms
loopback:security:access-context method upsert +1ms
loopback:security:access-context accessType WRITE +2ms
loopback:security:access-context accessToken: +1ms
loopback:security:access-context id "EoEwOGWIWLNfw4DLgxf9ga2zCoFht974DgCccMFkQLmLrmnQJ64eHJidDIf4e8dh" +2ms
loopback:security:access-context ttl 1209600 +2ms
loopback:security:access-context getUserId() 562a105037cfea381ac14fbb +1ms
loopback:security:access-context isAuthenticated() true +2ms
loopback:security:role Custom resolver found for role $owner +2ms
loopback:security:role isOwner(): Review 562a105037cfea381ac14fbe userId: 562a105037cfea381ac14fbb +2ms
loopback:security:role Model found: {"date":"2015-10-19T10:47:44.791Z","rating":5,"comments":"A very good coffee shop.","id":"562a105037cfea381ac14fbe","coffeeShopId":"562a105037cfea381ac14fb8","publisherId":"562a105037cfea381ac14fbb"} +5ms
loopback:security:role Checking relation reviewer to Reviewer: {"name":"reviewer","type":"belongsTo","modelFrom":"Review","keyFrom":"pulisherId","modelTo":"Reviewer","keyTo":"id","multiple":false} +4ms
loopback:security:acl The following ACLs were searched: +4ms
loopback:security:acl ---ACL--- +1ms
loopback:security:acl model Review +2ms
loopback:security:acl property * +1ms
loopback:security:acl principalType ROLE +1ms
loopback:security:acl principalId $everyone +1ms
loopback:security:acl accessType * +1ms
loopback:security:acl permission DENY +2ms
loopback:security:acl with score: +1ms 7495
loopback:security:acl ---ACL--- +1ms
loopback:security:acl model Review +1ms
loopback:security:acl property * +1ms
loopback:security:acl principalType ROLE +1ms
loopback:security:acl principalId $everyone +2ms
loopback:security:acl accessType READ +1ms
loopback:security:acl permission ALLOW +1ms
loopback:security:acl with score: +1ms -1
loopback:security:acl ---Resolved--- +1ms
loopback:security:access-context ---AccessRequest--- +1ms
loopback:security:access-context model Review +2ms
loopback:security:access-context property upsert +1ms
loopback:security:access-context accessType WRITE +1ms
loopback:security:access-context permission DENY +1ms
loopback:security:access-context isWildcard() false +2ms
loopback:security:access-context isAllowed() false +2ms

crandmck · 2015-10-28T23:36:36Z

@mike-aungsan I added a note to https://docs.strongloop.com/display/LB/Accessing+related+models#Accessingrelatedmodels-note.
Please let me know if there's any issue with it.

mike-aungsan · 2015-10-28T23:58:49Z

@crandmck Many Thanks

superkhau · 2016-02-04T19:48:39Z

Are you guys still running into issues? Can I close this?

jdhiro · 2016-02-04T19:54:26Z

The design seems undesirable, but as long as the design is documented (and it looks like it is from @crandmck post), I don't see a problem closing it. I worked around it in my project -- no longer an immediate concern.

superkhau · 2016-02-04T20:00:34Z

@jdhiro Sounds good. Please open a new issue if you guys are still running into issues. Better yet, submit a patch and we can go from there.

gekko68 · 2016-02-04T20:10:21Z

Yes - i do

sorry for this question but how do I enable the debug view ?

"You can run the application with DEBUG enabled:

$ DEBUG=loopback:security:* node . "

Thanks,

superkhau · 2016-02-04T20:40:09Z

sorry for this question but how do I enable the debug view ?

What do you mean debug view? Run DEBUG=loopback:security:* node . when starting your loopback app.

gekko68 · 2016-02-05T08:49:41Z

Hi,
got it working. Thx. U just run the application DEBUG=loopback:security:* node . on commandline .

emazzu · 2017-10-26T00:00:24Z

somebody can help me ? with the same themes ?

emazzu · 2017-10-26T00:00:48Z

if somebody can help me, I send the problem !!!

crandmck · 2017-10-26T17:37:16Z

https://loopback.io/doc/en/contrib/Reporting-issues.html#dont-use-an-issue-to-ask-a-question

emazzu · 2017-10-26T18:40:04Z

Execuse me, but on gitter nobody responds, and I cant resolve the problem, I dont know what I can do !!!

princecharmx · 2017-11-03T14:32:22Z

@emazzu @crandmck , i think this problem has come again in the latest repo. @raymondfeng , please look into it. This exposes the security loophole for the app in production.
Refer this thread #3518

princecharmx · 2017-11-23T09:39:49Z

@emazzu , @crandmck @raymondfeng , this problem is only with custom access token. I reverted to loopback AccessToken model than it started working as intended.

This was referenced Oct 21, 2014

establish SL metrics Angular SDK API #674

Closed

evaluate chrome dev-tools as metrics UI tool #675

Closed

superkhau added the triaging label Feb 26, 2015

mike-aungsan mentioned this issue Oct 23, 2015

Reviewers API { "error": { "name": "Error", "status": 401, "message": "Authorization Required" }} strongloop/loopback-getting-started-intermediate#12

Closed

superkhau added the doc label Oct 23, 2015

Amir-61 removed the triaging label Dec 23, 2015

superkhau closed this as completed Feb 4, 2016

Error "401 Authorization required" when querying methods involving relations #426

Error "401 Authorization required" when querying methods involving relations #426

Comments

sam-artuso commented Jul 31, 2014

daankets commented Aug 12, 2014

gcirne commented Aug 12, 2014

daankets commented Aug 12, 2014

dagumak commented Aug 19, 2014

fabien commented Aug 19, 2014

dagumak commented Aug 19, 2014

fabien commented Aug 19, 2014

fabien commented Aug 19, 2014

dagumak commented Aug 19, 2014

@dagumak the very least you could do is trace your current TestUser.settings.acls to compare them.

fabien commented Aug 19, 2014

dagumak commented Aug 19, 2014

fabien commented Aug 19, 2014

raymondfeng commented Aug 19, 2014

dagumak commented Aug 19, 2014

SwadhyayStudios commented Jan 31, 2015

SwadhyayStudios commented Jan 31, 2015

rubentorresbonet commented Feb 7, 2015

superkhau commented Feb 26, 2015

LetsDoIt- commented Feb 26, 2015

rubentorresbonet commented Feb 26, 2015

jdhiro commented Aug 2, 2015

csvan commented Sep 10, 2015

csvan commented Sep 10, 2015

mike-aungsan commented Oct 23, 2015

superkhau commented Oct 23, 2015

vnathalye commented Oct 23, 2015

crandmck commented Oct 28, 2015

mike-aungsan commented Oct 28, 2015

superkhau commented Feb 4, 2016

jdhiro commented Feb 4, 2016

superkhau commented Feb 4, 2016

gekko68 commented Feb 4, 2016

superkhau commented Feb 4, 2016

gekko68 commented Feb 5, 2016

emazzu commented Oct 26, 2017

emazzu commented Oct 26, 2017

crandmck commented Oct 26, 2017

emazzu commented Oct 26, 2017

princecharmx commented Nov 3, 2017 • edited

princecharmx commented Nov 23, 2017

princecharmx commented Nov 3, 2017 •

edited