findById does not include "options", but find does?

[DaGaMs]

Description/Steps to reproduce

According to the new remoting context injection #3023 I expect to always get an options property in the current context of an operation hook. I have a mixin that will restrict the requested object to the current owner (and in the future other team members, so I can't use $owner):

module.exports = function(Model, options) {
 Model.observe('access', function limitToTenant(ctx, next) {
 var userId = ctx.options.accessToken.userId;
 if (!userId) {
 console.error("No user in context ", ctx.options);
 var error = new Error("Not authorized");
 error.statusCode = 401;
 next(error);
 }
 if (_.has(ctx,'query')) {
 if (_.has(ctx.query, 'where')) {
 var old = ctx.query.where;
 ctx.query.where = {and: [old, {ownerId: userId}]};
 }
 else {
 ctx.query.where = {ownerId: userId};
 }
 }
 next();
 });
};

This works just fine when I do a request like this: /api/projects?filter[where][id]=1, but when I do a request like this: /api/projects/1, the options parameter is empty.

Expected result

I expect invocation of find and findById to both propagate the options to operation hooks.

Additional information

Here is the model definition file:

{
 "name": "project",
 "base": "PersistedModel",
 "strict": true,
 "idInjection": true,
 "replaceOnPUT": false,
 "options": {
 "validateUpsert": true
 },
 "mixins": {
 "AccessControl": {}
 },
 "mysql": {
 "schema": "testdb",
 "table": "Project"
 },
 "properties": {
 "lastUpdated": {
 "type": "date",
 "required": true,
 "length": null,
 "dataType": "timestamp",
 "nullable": "N"
 },
 "created": {
 "type": "date",
 "required": true,
 "index": -1,
 "dataType": "datetime",
 "nullable": "N" 
 },
 "name": {
 "type": "string",
 "required": false,
 "length": 256,
 "index": 1,
 "nullable": "Y"
 }
 },
 "validations": [],
 "relations": {
 "owner": {
 "model": "Person",
 "type": "belongsTo"
 }
 },
 "acls": [
 {
 "accessType": "*",
 "principalType": "ROLE",
 "principalId": "$everyone",
 "permission": "DENY"
 },
 {
 "accessType": "*",
 "principalType": "ROLE",
 "principalId": "$authenticated",
 "permission": "ALLOW",
 "property": "count"
 },
 {
 "accessType": "*",
 "principalType": "ROLE",
 "principalId": "$authenticated",
 "permission": "ALLOW",
 "property": ["all", "find", "findOne", "findById", "findOrCreate", "create", "getIdName", "getSourceId"]
 },
 {
 "accessType": "*",
 "principalType": "ROLE",
 "principalId": "$owner",
 "permission": "ALLOW"
 }
 ],
 "methods": {
 }
}

Versions

$ npm ls --prod --depth 0 | grep loopback
├── loopback@3.2.1
├── loopback-boot@2.23.0
├── loopback-component-explorer@4.0.0
├── loopback-component-passport@2.1.4 (git://github.com/dagams/loopback-component-passport.git#db99e72a8fcf7291c6803c70b7c4ebc256c0ea3e)
├── loopback-connector-mysql@3.0.0
├── loopback-datasource-juggler@3.2.0

[DaGaMs]

Ok, I have narrowed this down a bit now. The problem is not actually with findById, but with the ACL settings. I must be missing some important ACL property somewhere, but I'm not sure what it is. I created a repo with a minimal project based on the Note example of strongloop 3.0. Just type mocha to run the test cases.

https://github.com/DaGaMs/loopback_context_test

[DaGaMs]

Some more information. When I run with DEBUG="*", I can see that in the working test case, the ACL resolver seems to "do the right thing", i.e. resolve to isOwner=true, see this gist;

On the other hand, in the test case that fails, I get this output, which differs in the following two lines which don't appear in the passing test:

loopback:security:role isOwner(): Note 1 userId: 1 principalType: USER +1ms
loopback:security:role Model not found for id "1" +0ms

This does look like a bug to me, but I'm not sure where it's coming from.

[DaGaMs]

So, simply removing the last part of the access control list makes the tests pass:

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

It seems that there's really some very peculiar bug that only strikes when the dynamic $owner role is resolved in a findById query.

[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.