This repository has been archived by the owner on Aug 28, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 175
Cannot read property 'keys' of undefined #90
Labels
Comments
After some investigation found that issue connected with this,
jwtVerify function doesn't wait for metadata.fetch method's successful completion. |
Strange. This can be fixed with a waterfall and I thought I'd had done so. I'll look in to this now and get a fix in by EOW. |
Are there any updates on this? |
lovemaths
added a commit
that referenced
this issue
Jul 6, 2016
Metadata loading is async, passport may use the metadata content even if the metadata loading is not finished, for instance, keys. In this fix, the following are done: (1) load metadata dynamically at `authenticate` time, from server or memory cache (2) solved async issue using waterfall (3) added a couple of unit tests
lovemaths
added a commit
that referenced
this issue
Jul 7, 2016
Metadata loading is async, passport may use the metadata content even if the metadata loading is not finished, for instance, keys. In this fix, the following are done: (1) load metadata dynamically at `authenticate` time, from server or memory cache (2) solved async issue using waterfall (3) added a couple of unit tests
lovemaths
added a commit
that referenced
this issue
Jul 13, 2016
BearerStrategy used to inherit from passport-http-bearer strategy https://github.com/jaredhanson/passport-http-bearer/ when BearerStrategy is created, it reads the info (from developer and metadata). In the authentication time, passport-http-bearer does all the work using these info read at the BearerStrategy's creation time. This is not good since: (1) for B2C, different policy may have different metadata, so the metadata should be loaded dynamically (and cached) in the authentication time based on the request (2) async issue, metadata loading is async, passport-http-bearer's `authenticate` function depends on the metadata, and it might be called before the metadata loading finishes. This is in fact the cause of this bug, where we validate the token before we load the keys from metadata url. In this fix, the following are done: (1) load metadata dynamically at `authenticate` time, from server or memory cache (2) solved async issue using waterfall (3) added a couple of unit tests
lovemaths
added a commit
that referenced
this issue
Jul 13, 2016
BearerStrategy used to inherit from passport-http-bearer strategy https://github.com/jaredhanson/passport-http-bearer/ when BearerStrategy is created, it reads the info (from developer and metadata). In the authentication time, passport-http-bearer does all the work using these info read at the BearerStrategy's creation time. This is not good since: (1) for B2C, different policy may have different metadata, so the metadata should be loaded dynamically (and cached) in the authentication time based on the request (2) async issue, metadata loading is async, passport-http-bearer's `authenticate` function depends on the metadata, and it might be called before the metadata loading finishes. This is in fact the cause of this bug, where we validate the token before we load the keys from metadata url. In this fix, the following are done: (1) load metadata dynamically at `authenticate` time, from server or memory cache (2) solved async issue using waterfall (3) added a couple of unit tests
lovemaths
added a commit
that referenced
this issue
Jul 13, 2016
BearerStrategy used to inherit from passport-http-bearer strategy https://github.com/jaredhanson/passport-http-bearer/ when BearerStrategy is created, it reads the info (from developer and metadata). In the authentication time, passport-http-bearer does all the work using these info read at the BearerStrategy's creation time. This is not good since: (1) for B2C, different policy may have different metadata, so the metadata should be loaded dynamically (and cached) in the authentication time based on the request (2) async issue, metadata loading is async, passport-http-bearer's `authenticate` function depends on the metadata, and it might be called before the metadata loading finishes. This is in fact the cause of this bug, where we validate the token before we load the keys from metadata url. In this fix, the following are done: (1) load metadata dynamically at `authenticate` time, from server or memory cache (2) solved async issue using waterfall (3) added a couple of unit tests
lovemaths
added a commit
that referenced
this issue
Jul 13, 2016
BearerStrategy used to inherit from passport-http-bearer strategy https://github.com/jaredhanson/passport-http-bearer/ when BearerStrategy is created, it reads the info (from developer and metadata). In the authentication time, passport-http-bearer does all the work using these info read at the BearerStrategy's creation time. This is not good since: (1) for B2C, different policy may have different metadata, so the metadata should be loaded dynamically (and cached) in the authentication time based on the request (2) async issue, metadata loading is async, passport-http-bearer's `authenticate` function depends on the metadata, and it might be called before the metadata loading finishes. This is in fact the cause of this bug, where we validate the token before we load the keys from metadata url. In this fix, the following are done: (1) load metadata dynamically at `authenticate` time, from server or memory cache (2) solved async issue using waterfall (3) added a couple of unit tests
lovemaths
added a commit
that referenced
this issue
Jul 14, 2016
BearerStrategy used to inherit from passport-http-bearer strategy https://github.com/jaredhanson/passport-http-bearer/ when BearerStrategy is created, it reads the info (from developer and metadata). In the authentication time, passport-http-bearer does all the work using these info read at the BearerStrategy's creation time. This is not good since: (1) for B2C, different policy may have different metadata, so the metadata should be loaded dynamically (and cached) in the authentication time based on the request (2) async issue, metadata loading is async, passport-http-bearer's `authenticate` function depends on the metadata, and it might be called before the metadata loading finishes. This is in fact the cause of this bug, where we validate the token before we load the keys from metadata url. In this fix, the following are done: (1) load metadata dynamically at `authenticate` time, from server or memory cache (2) solved async issue using waterfall (3) added a couple of unit tests
lovemaths
added a commit
that referenced
this issue
Jul 14, 2016
Solved #90: Cannot read property 'keys' of undefined
done |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hey
We have a node js server, that running using your library for authentication.
There is a exception thrown from it.
Or some times it rejects valid json token, and messages, "An error was received validating the token secret or public key must be provided". I think it happens because at the time when token comes for validation the public key hasn't downloaded yet. For reproduce this issue I stop and start node server, and immediately after that make request. On later requests with the same token there isn't any issue.
Below is my node code.
Any help appreciated.
Thanks,
Sash
The text was updated successfully, but these errors were encountered: