404 response from populateUser() hook

[Chris-R3]

If I request a resource with a token for a user who got deleted, I get a 404 response:

{
  "name": "NotFound",
  "message": "No record found for id '579fff74c56273102c131c3b'",
  "code": 404,
  "className": "not-found",
  "errors": {}
}

How can I distinguish between a non-existent user and an actual missing resource?

[ekryski]

Right now it's not that easy. The only thing you can do is register your own error middleware to try and detect where the request went to, what they were requesting and if it is actually missing.

feathers-authentication@0.8.0 is changing so that you don't have to call the populateUser() hook. It is being moved to middleware that gets run and doesn't throw an error if the user isn't found.

I'm going to have to think about this. Any reason you can't just treat them the same? Regardless of whether they were deleted, it's still now a missing record and an invalid id.

[daffl]

I think the idea is to get a different error message (Invalid user or something).

In the new auth we'd just check for a params.user to exist and then throw an error though so this might not be relevant anymore.

[ekryski]

agreed the new version will completely resolve this.

[Chris-R3]

A different error message would have been nice, but if that behaviour is changed in the next version of feathers-authenticate then thats fine for me.

The idea was to show a login form if the user id is wrong/no longer exists and otherwise show a 404 page for missing resources. The issue came up after resetting the database. I still had the old token stored in the browser but from the error message it wasn't really clear that the user is was no longer valid.

[ekryski]

If the user is missing it will now return a proper 404 error code with v1.x of auth. Let us know if you are still having issues and we'd be happy to revisit.

[Chris-R3]

Actually I'm getting no error at all!

To recap:

1. user signs in with local auth and gets back a jwt
2. user is deleted from the db
3. user can still access all resources with the token from step 1!

Is this the intended behaviour until the token expires?