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

├── loopback@3.2.1
├── loopback-boot@2.23.0
├── loopback-component-explorer@4.0.0
├── loopback-component-push@1.7.0
├── loopback-component-storage@3.0.0
├── loopback-connector-mongodb@3.0.0

[faridnsh]

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.

[faridnsh]

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, ***@***.***> wrote: Seems like same issue at #1441 <#1441>. You can also try my workaround which I described in here <#1441 (comment)> : 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 <#3121 (comment)>, 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, <lunchtime@nxtlvl.gg> 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, <notifications@github.com> wrote: Seems like same issue at #1441 <#1441>. You can also try my workaround which I described in here <#1441 (comment)>: 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 <#3121 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADQw9BE1woUIo0eIpmpOKjvcNm7xyZs1ks5ra-NlgaJpZM4LomP5> .

[matias-casal]

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 strongloop/loopback-workspace#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 #3198 (comment), you also need to update the data already stored in your MongoDB database to fix the type of the relevant id fields.