Loopback: Rolemapping only accept principalId where with like

[felipetoffolo1]

Bug/Feature request

After i upgraded Loopback to version 3, This filter o rolemapping returns nothing
{"where":{"principalId":"5880038427758463a1ae5a3b"}}
i changed my filter to this
{"where":{"principalId":{ "like": "5880038427758463a1ae5a3b"}}}
and it worked. But is it a bug? Or it changed onn the new version? (i did not find anything about it in migration docs)

Expected result

Expected
filter{"where":{"principalId":"5880038427758463a1ae5a3b"}} to return results

Actual
it returns nothing

Additional information

linux x64 7.4.0

├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]

[alFReD-NSH]

Try converting "5880038427758463a1ae5a3b" to object id.

[totalard]

How i do that?

[luncht1me]

Converting to ObjectID doesn't work. I'm having the same problem.

Trying to find a RoleMapping using principalId in the where query returns nothing.
If I try and find it as a regex of the Id string it works.
principalId is stored as a string in mongodb.

Something, somewhere, in either connector-mongodb or datasource-juggler is breaking the string query for principalId. I can query any other field and get a result except the principalId.

I'm sure you can understand the dangers of querying with a regex instead of an exact string match...

[luncht1me]

Just a debug output:

  loopback:connector:mongodb all +2ms RoleMapping { where:
   { roleId: 589b917cc889c618f09ca889,
     principalId: '589b917cc889c618f09ca888' } }
  loopback:connector:mongodb MongoDB: model=RoleMapping command=find +2ms [ { roleId: 589b917cc889c618f09ca889,
    principalId: 589b917cc889c618f09ca888 },
  [Function] ]

In the first output, the principalId is a string, as seen by the quotes. But then the next output, principalId is no longer a string but an actual Id. I'm assuming this casting here is what's breaking the query.

[luncht1me]

After lots of debugging. I've come to a solution.

In loopback's default common/models/role-mapping.json, added "strictObjectIDCoercion": true to the model definition.
Now principalId can be queried properly.

resulting node_modules/loopback/common/models/role-mapping.json:

{
  "name": "RoleMapping",
  "description": "Map principals to roles",
  "strictObjectIDCoercion": true,
  "properties": {
    "id": {
      "type": "string",
      "id": true,
      "generated": true
    },
    "principalType": {
      "type": "string",
      "description": "The principal type, such as user, application, or role"
    },
    "principalId": {
      "type": "string",
      "index": true
    }
  },
  "relations": {
    "role": {
      "type": "belongsTo",
      "model": "Role",
      "foreignKey": "roleId"
    }
  }
}

Can we get this change persisted to loopback?? Thanks.

[alFReD-NSH]

Seems like same issue at #1441. You can also try my workaround which I described in here:

var ObjectID = RoleMapping.getDataSource().connector.getDefaultIdType();

// Because of this: https://github.com/strongloop/loopback-connector-mongodb/issues/1441
RoleMapping.defineProperty('principalId', {
  type: ObjectID,
});

[luncht1me]

this requires overwriting the internal RoleMapping model. We shouldn't have
to do this for default intended functionality.

The fact remains theres a discrepancy and inconsistency between
RoleMapping's definition of principalId and how it's being handled in
queries.

On Thu, Feb 9, 2017, 8:11 PM Farid Nouri Neshat, [e-mail]
wrote:

Seems like same issue at #1441
https://github.com/strongloop/loopback/issues/1441. You can also try my
workaround which I described in here
https://github.com/strongloop/loopback/issues/1441#issuecomment-180767939
:

var ObjectID = RoleMapping.getDataSource().connector.getDefaultIdType();

// Because of this: https://github.com/strongloop/loopback-connector-mongodb/issues/1441
RoleMapping.defineProperty('principalId', {
type: ObjectID,
});

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/strongloop/loopback/issues/3121#issuecomment-278853028,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADQw9BE1woUIo0eIpmpOKjvcNm7xyZs1ks5ra-NlgaJpZM4LomP5
.

[luncht1me]

but thankyou for the alternate work around.

On Thu, Feb 9, 2017, 11:38 PM Colin Johnson, [e-mail] wrote:

this requires overwriting the internal RoleMapping model. We shouldn't have
to do this for default intended functionality.

The fact remains theres a discrepancy and inconsistency between
RoleMapping's definition of principalId and how it's being handled in
queries.

On Thu, Feb 9, 2017, 8:11 PM Farid Nouri Neshat, [e-mail]
wrote:

Seems like same issue at #1441
https://github.com/strongloop/loopback/issues/1441. You can also try my
workaround which I described in here
https://github.com/strongloop/loopback/issues/1441#issuecomment-180767939:

var ObjectID = RoleMapping.getDataSource().connector.getDefaultIdType();

// Because of this:
https://github.com/strongloop/loopback-connector-mongodb/issues/1441
RoleMapping.defineProperty('principalId', {
type: ObjectID,
});

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/strongloop/loopback/issues/3121#issuecomment-278853028,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADQw9BE1woUIo0eIpmpOKjvcNm7xyZs1ks5ra-NlgaJpZM4LomP5
.

[StarkTS]

I try with @luncht1me solutions but still have this issue.

after a few test, the problem is with all the ids in mongodb, its not just about the roleMapping

[bajtos]

cc @fabien I know you are using the MongoDB connector a lot, have you encountered this issue too? Can you think of any advice on how to fix it in user-land?

[bajtos]

Seems like same issue at #1441

Can we close this issue as a duplicate of #1441 then? /cc @alFReD-NSH

[fabien]

@bajtos here's what I have in a bootscript - it works fine:

var RoleMapping = app.models['RoleMapping'];
RoleMapping.settings.strictObjectIDCoercion = true;

[bajtos]

Hello, I submitted https://github.com/strongloop/loopback-workspace/pull/437 that will enable strictObjectIDCoercion for all new applications scaffolded using our lb/apic/slc tooling.

For existing applications, you can either add a boot script as @fabien shown above, or you can enable the setting via server/model-config.json:

{
  "RoleMapping": {
    "dataSource": "db",
    "options": {
      "strictObjectIDCoercion": true
    },
    "public": false
  }
}

As part of the update, according to https://github.com/strongloop/loopback/pull/3198#issuecomment-280382924, you also need to update the data already stored in your MongoDB database to fix the type of the relevant id fields.

[bajtos]

I am closing this issue as resolved.

[pr3mar]

This error still exists.

[bajtos]

@pr3mar

This error still exists.

Please open a new GitHub issue and provide us with instruction how to reproduce the error you are seeing, see http://loopback.io/doc/en/contrib/Reporting-issues.html#bug-report