Logout fails for model based on User (other than model called "user")

[johnsoftek]

If you create a model, say Appuser, based on User, when you call Appuser.logout, it fails with:

.../server/node_modules/loopback/lib/models/user.js:232
  this.relations.accessTokens.modelTo.findById(tokenId, function (err, accessT
                             ^
TypeError: Cannot read property 'modelTo' of undefined

[raymondfeng]

Your Appuser model should have a hasMany relation named accessTokens to the access token model. But I think it should be inherited from the base User model. I'll check.

[johnsoftek]

Raymond,

Yes, it works better if I create an accessToken model based on

AccessToken and declare the hasMany relation to accessToken. Something
still fails and I don't have time to pursue it at this stage.

John Murphy

On 25 July 2014 01:40, Raymond Feng notifications@github.com wrote:

Your Appuser model should have a hasMany relation named accessTokens to
the access token model. But I think it should be inherited from the base
User model. I'll check.

—
Reply to this email directly or view it on GitHub
#398 (comment).

[bajtos]

@raymondfeng are the model relations inherited? I.e. when you create Appuser based on User, will it inherit the relation Appuser hasMany accessTokens? If relations are not inherited, is there any good reason why we should not implement that in the future?

[hungtuchen]

this issue still exist, the new user model based on user will not inherit the relation
add relation by hand can bypass this issue

[Silvercast]

I'm suffering the same issue. I have Appuser model which has a hasMany relation to accessTokens model. And it doesn't work , giving error 500 when logout :(

[raymondfeng]

@Silvercast Did you pass in access_token during logout?

[Silvercast]

Thanks. I managed to fix it by manually removing the hasMany relation in my custom Appuser model. Work as expected.
I was confused by comments above.

[sn-satyendra]

Is this issue fixed. I am still getting the 500 error when I try to logout the user with access_token. I have a appuser which is extended from in built model User. appuser has a hasMany relation to accessToken. accessToken has been extended from in built model AccessToken
@Silvercast I tried removing the hasMany relation in appuser but then I got the below issue at the time of login:

TypeError: Cannot read property 'create' of undefined
at ModelConstructor.User.createAccessToken (D:\zv\node_modules\loopback\common\models\user.js:100: 22)
at D:\zv\node_modules\loopback\common\models\user.js:256: 22
at D:\zv\node_modules\loopback\common\models\user.js:312: 9
at D:\zv\node_modules\loopback\node_modules\bcryptjs\dist\bcrypt.js:261: 17
at D:\zv\node_modules\loopback\node_modules\bcryptjs\dist\bcrypt.js:1198: 21
at Immediate.next (D:\zv\node_modules\loopback\node_modules\bcryptjs\dist\bcrypt.js:1078: 21)
at Immediate._onImmediate (D:\zv\node_modules\loopback\node_modules\continuation-local-storage\node_modules\async-listener\glue.js:188: 31)
at processImmediate [as _immediateCallback](timers.js:358: 17)

[superkhau]

Are you guys still running into this issue? I'm closing it for now, ping and I will reopen.

[mcitdev]

same here,

TypeError: Cannot read property 'modelTo' of undefined
    at node_modules/loopback/common/models/user.js:350:58

// user.js:350:58
User.observe('before delete', function(ctx, next) {
    var AccessToken = ctx.Model.relations.accessTokens.modelTo;
    var pkName = ctx.Model.definition.idName() || 'id';
    ctx.Model.find({where: ctx.where, fields: [pkName]}, function(err, list) {
      if (err) return next(err);

      var ids = list.map(function(u) { return u[pkName]; });
      ctx.where = {};
      ctx.where[pkName] = {inq: ids};

      AccessToken.destroyAll({userId: {inq: ids}}, next);
    });
  });

I managed to fix it by manually wrapping the content in an "if() else" statement like so :

User.observe('before delete', function(ctx, next) {

   if(ctx.Model.relations.accessTokens !== undefined) {

      var AccessToken = ctx.Model.relations.accessTokens.modelTo;
      var pkName = ctx.Model.definition.idName() || 'id';
      ctx.Model.find({where: ctx.where, fields: [pkName]}, function(err, list) {
        if (err) return next(err);
        var ids = list.map(function(u) { return u[pkName]; });
        ctx.where = {};
        ctx.where[pkName] = {inq: ids};
        AccessToken.destroyAll({userId: {inq: ids}}, next);
      });

   }
   else
      next();
  });

Hope this will be fixed soon, because the work arround listed in the comments above does not work for me ! Especially that the relation "accessTokens" already exists on User model, and it should be inherited by his children !!! things that seems not heppens here ??????

[bajtos]

@mcitdev thank you for the update. If I understand your situation correctly, you have a custom User model that does not have any accessTokens relation configured, is that correct? That sounds more like a configuration problem of the application than a bug in the framework. We are trying to detect that at runtime and print a warning. See also our documentation on how to correctly setup custom User and/or AccessToken models: http://loopback.io/doc/en/lb3/Authentication-authorization-and-permissions.html#preparing-access-control-models

Please pardon me if I have misunderstood your scenario, it's difficult to build a good understanding only from the code snippet you have provided.

To move this issue forward, I need either a small app reproducing the issue (see our bug reporting instructions) or if you are feeling brave then you can open a pull request to fix the issue and write unit-test reproducing the problem in that pull request.

[mcitdev]

The situation is that I've created a custom user based on the User model, just for the test, and I didn't use the acl, so I can access the data in the database without needing to login. So, yes the user does not have any accessTokens. So when I try to delete some entries from the database, the hooks above User.observe('before delete', function(ctx, next) search for accessTokens that actually not exists, and the error is thrown.

Tha's why I use the workaround above.
Maybe I needed just to create a custom user based on a persistedModel, because the User model forces you to use acl, to login and get an accessToken to perform the delete action, if else the server crashes.

But I agree that a warning in this situation would be very nice than crashing the app, especially that I intentionally choose to not use acl.