Unauthorized access permitted when using multiple user models

[bencallaway]

Description

Using the setup suggested by the docs for controlling access with multiple user models, it appears that a user A may access info about user B.

Sample repo

https://github.com/bencallaway/loopback-sandbox

Test case

A test for the scenario can be run with npm test, and not so surprisingly found at test/test.js.

Steps to reproduce

1. Setup Customer and Admin models based on User
2. Setup a CustomAccessToken model based on AccessToken
3. Setup a polymorphic hasMany "accessTokens" relation from Customer and Admin to CustomAccessToken with "userId" as the foreign key and "principalType" as the discriminator
4. Setup a polymorphic belongsTo "user" relation from CustomAccessToken with "userId" as the foreign key and "principalType" as the discriminator
5. Create a Customer account
6. Create an Admin account
7. Login as Customer
8. GET /admins/{customer_id}?access_token={customer_access_token} returns the admin who happens to have the same numeric id

Expected result

The server should respond with a 401.

Actual result

The server responds with a 200. The admin’s information is returned in the response body.

Additional information

darwin x64 8.1.3

loopback-sandbox@1.0.0
├── loopback@2.38.3
├── loopback-boot@2.25.0
├── loopback-component-explorer@2.7.0
├── loopback-datasource-juggler@2.55.0

[ebarault]

Are you using MySQL or any db not using a random guid as key?
If yes then it's a known issue of the dual user set-up.
In order to mitigate it you can generate your own unique ids in the meantime

[bencallaway]

@ebarault Yes, I'm using PostgreSQL with integer ids. Do you know of any URLs pertaining to this as a known issue?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

[lehni]

@ebarault mentioned that #3140 is related to this, which was just merged.

But there are untackled problems still, mainly this: e17132d#r104612589

I am reopening as this still needs resolving.

[lehni]

@bencallaway are you aware that your sandbox is for LB2? I've just upgraded all the dependencies to the latest LB3 versions, and the unit test now passes! This is probably due to #3140 recently landing?

I think we can savely close this now. Below the important bits of package.json that I used to make the test pass:

{
  "name": "loopback-sandbox",
  "main": "server/server.js",
  "scripts": {
    "lint": "eslint .",
    "start": "node .",
    "test": "mocha test",
    "posttest": "npm run lint && nsp check"
  },
  "dependencies": {
    "compression": "^1.7.0",
    "cors": "^2.8.4",
    "helmet": "^3.8.0",
    "loopback": "^3.14.0",
    "loopback-boot": "^2.26.1",
    "loopback-component-explorer": "^5.0.0",
    "serve-favicon": "^2.0.1",
    "strong-error-handler": "^2.2.0"
  },
  "devDependencies": {
    "eslint": "^4.8.0",
    "eslint-config-loopback": "^8.0.0",
    "mocha": "^4.0.0",
    "nsp": "^2.8.0",
    "supertest": "^3.0.0"
  }