handling Invalid Access Token error

[Partap Davis]

When an access token expires, I sometimes get an uncaught exception on the server, "Invalid Access Token".

It doesn't happen all the time...I think just the first request since it expired, and if I resend the request, it is handled normally (ie: as an anonymous user)

What's the best way to gracefully handle the exception?  I'd like to either return a json 401 error object or process the request as an anonymous user, depending on the request.

Also, how can I attach a default exception handler to the http pipeline?  For instance, if I run into a random unhandled exception, I'd like to respond with a 500 error...

Thanks,

-partap

[David Castro]

I'm having the same issue, 

I'm not sure how/where I can control the elimination of this tokens. I noticed that Loopback is presenting this error page when the Token is too ald and is automatically removing it frmo the DB.

Is there any way to control this behaviour?

Thanks a lot, 

DC

[Mikael Jensen]

Have the same problem:

Loopback: 2.31.0

Stacktrace is a bit unhelpful and I only get this in production, so limited debug options

Error: Invalid Access Token

    at [proj_root]/node_modules/loopback/common/models/access-token.js:110:23

    at [proj_root]/node_modules/loopback/common/models/access-token.js:155:11

    at [proj_root]/node_modules/loopback-datasource-juggler/lib/dao.js:2514:17

    at doNotify ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:98:49)

    at doNotify ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:98:49)

    at doNotify ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:98:49)

    at doNotify ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:98:49)

    at Function.ObserverMixin._notifyBaseObservers ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:121:5)

    at Function.ObserverMixin.notifyObserversOf ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:96:8)

    at Function.ObserverMixin._notifyBaseObservers ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:119:15)

    at Function.ObserverMixin.notifyObserversOf ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:96:8)

    at Function.ObserverMixin._notifyBaseObservers ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:119:15)

    at Function.ObserverMixin.notifyObserversOf ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:96:8)

    at Function.ObserverMixin._notifyBaseObservers ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:119:15)

    at Function.ObserverMixin.notifyObserversOf ([proj_root]/node_modules/loopback-datasource-juggler/lib/observer.js:96:8)

    at [proj_root]/node_modules/loopback-datasource-juggler/lib/dao.js:2513:21

[Philippe Corrèges]

Hi !

Did you find any solution ?

Cheers,

Philippe

[Mikael Jensen]

Nope. 

Still have the problem. 

2 days ago:

IBGv4-10 (err): Error: Invalid Access Token

IBGv4-10 (err):     at [project_root]/node_modules/loopback/common/models/access-token.js:110:23

IBGv4-10 (err):     at [project_root]/node_modules/loopback/common/models/access-token.js:155:11

IBGv4-10 (err):     at [project_root]/node_modules/loopback-datasource-juggler/lib/dao.js:2514:17

Any suggestion on solution or toubleshooting is most welcome

[Janny Hou]

Hi Partap

I am trying to reproduce it.

Could you fork https://github.com/strongloop/loopback-sandbox and replace with your code?

Appreciate it if you can contain the reproduce steps :-)

I will create a bug issue in loopback after confirming.

Thanks!

[Partap Davis]

Funny...it just happened to me again and then I saw this reply in my inbox.

I think the easiest way to reproduce would be to set new access tokens to expire almost immediately...say 1 minute in the future.  Not sure how to do that offhand though, I haven't worked on this code in quite a while...  

Anyway, I'm thinking that if you have a quick expiring access token, you could just login and close the page, then open it again after you're sure it has expired.  

Part of the problem with tracking this down has been that it only happens after I'm away from the project for a while and I forget about it.  Later, when I have something I need to do with the project, I open up the page and get the error, but it goes away on refresh and I already have something else I need to be working on...

On Tue, Oct 4, 2016 at 2:13 PM, Janny Hou <jannyh...@gmail.com> wrote:

Hi Partap

I am trying to reproduce it.

Could you fork https://github.com/strongloop/loopback-sandbox and replace with your code?

Appreciate it if you can contain the reproduce steps :-)

Thanks!

--
You received this message because you are subscribed to a topic in the Google Groups "LoopbackJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/loopbackjs/6CmxkF4ed6k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to loopbackjs+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/loopbackjs/4b0a8111-400c-4dd4-a500-09c4208dd4ed%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[mha...@mademovement.com]

A way to reproduce this issue is to login your user with a ttl property set to -1.

{

"username": "myUsername",

"password": "myPassword",
"ttl": -1

} 

Then access something that requires authetication/Authorization and you will get the error message:

{ "error": { "statusCode": 401, "name": "Error", "message": "Invalid Access Token", "status": 401, "code": "INVALID_TOKEN"

} }

This is an adequate error messages for most instances.

This problem is figuring out how to format that error message so it matches ones desired response signature

example:

{ "error": { "statusCode": 401, "code": 401, "error": true, "errors": [ { "message": "Invalid Access Token. Please try login in" } ], "data": [] } }

[Mikael Jensen]

Not really the same scenario. 

The problem concerns a unhandled exception that actually crashed the server, where as a 401 response is valid and the correct way of handling the situation.