Loopback: Multiple user models: ACL does not work.

[TwistedLogic]

Description/Steps to reproduce

Steps to reproduce the issue in the README of the sandbox repository.

Link to reproduction sandbox

https://github.com/TwistedLogic/loopback-sandbox-ACL-bug

Expected result

The ACL should work.

[Nop0x]

Hopefully this gets adressed. Having the same exact issue right now and haven't been able to find a solution to it.

[capitanomikejobs]

Hello everyone,
i have the same problem.
Any news from loopback team ?

[jannyHou]

@TwistedLogic Thank you for creating the sandbox app, I reproduced your error. Will take a look asap.

[Nop0x]

Hey @TwistedLogic, thanks for looking into this.

Are there any updates on this topic?

[lonewolfaka9]

I have a somewhat similar issue.

I've two type of custom user models :
siteAdmins
regularUser (moderator/buisness/user)

I want the user authenticated in siteAdmins endpoint to be able to manage regularUser model

somewhat ACL (regularUser) i'm using is not working

{
"accessType": "*",
"principalType": "siteAdmins",
"principalId": "$everyone",
"permission": "ALLOW"
}

[voratham]

I just delete code below, but loopback will lose authenticate from user model is provided.
/server/boot/authentication.js

module.exports = function enableAuthentication(server) {
  // enable authentication
   server.enableAuth();
};

[lonewolfaka9]

I just delete code below, but loopback will lose authenticate from user model is provided.
/server/boot/authentication.js

module.exports = function enableAuthentication(server) {
  // enable authentication
   server.enableAuth();
};

i'm able to generate authToken. but ACL are not working properly
consider this situation

siteAdmin should be able to CRUD regularUser

and regularUser shall able to find regularUser but not able to edit update or delete them.

if i put ACL that allows $owner to Update delete then siteAdmin are not able to edit them

[bajtos]

When I start the application provided in https://github.com/TwistedLogic/loopback-sandbox-ACL-bug, the following warning is printed:

The app configuration follows the multiple user models setup as described in http://ibm.biz/setup-loopback-auth The built-in role resolver $owner is not currently compatible with this configuration and should not be used in production.
The model "AccessToken" configures "belongsTo User-like models" relation with target model "User". However, the model "User" is not attached to the application and therefore cannot be used by this relation. This typically happens when the application has a custom custom User subclass, but does not fix AccessToken relations to use this new model.
Learn more at http://ibm.biz/setup-loopback-auth

The problem you are experiencing is most likely caused by the misconfiguration as warned about.

Specifically:

• The built-in AccessToken model should be removed from server/model-config.json
• The token middleware must be configured to use CustomAccessToken model, as explained in https://loopback.io/doc/en/lb3/Authentication-authorization-and-permissions.html#access-control-with-multiple-user-models

Here is the relevant patch to apply to your sandbox app:

diff --git a/server/middleware.json b/server/middleware.json
index fbfff81..991f596 100644
--- a/server/middleware.json
+++ b/server/middleware.json
@@ -31,7 +31,13 @@
     }
   },
   "session": {},
-  "auth": {},
+  "auth": {
+    "loopback#token": {
+      "params": {
+        "model": "CustomAccessToken"
+      }
+    }
+  },
   "parse": {},
   "routes": {
     "loopback#rest": {
diff --git a/server/model-config.json b/server/model-config.json
index 5ac2b0f..d2ebc70 100644
--- a/server/model-config.json
+++ b/server/model-config.json
@@ -26,10 +26,6 @@
       }
     }
   },
-  "AccessToken": {
-    "dataSource": "db",
-    "public": false
-  },
   "CustomAccessToken": {
     "dataSource": "db",
     "public": false

With these two changes in place, the scenario described in sandbox's README seems to work well.