jwt.verify() not truly async.
See original GitHub issueDespite the verify action is in fact synchronize, the callback API does not.
It is specifically this line that released Zalgo.
Which can be fixed by wrapping it as such
done = function(err, data) {
setImmediate(callback, err, data);
};
Issue Analytics
- State:
- Created 5 years ago
- Comments:8 (2 by maintainers)
Top Results From Across the Web
Node.js callback for jwt.verify() - Stack Overflow
verify() method with two options: Asynchronous: If a callback is supplied, function acts asynchronously. The callback is called with the decoded ...
Read more >Why does jsonwebtoken's verify method async? : r/node - Reddit
Hey all, I have been looking through json web token libraries and came across jsonwebtoken. As you can see over here…
Read more >How to use the jsonwebtoken.verifyAsync function in ... - Snyk
it('should make a valid JWT', async () => { const jToken = token.tokenString(); const decoded = await jwt.verifyAsync(jToken, config.secret); expect(decoded, ' ...
Read more >jsonwebtoken.verify JavaScript and Node.js code examples
async parse(token) { if (token) { try { return jwt.verify(token, ... it('should use algorithm from key header to verify id_token', async () =>...
Read more >jsonwebtoken - npm
If jwt.verify is called asynchronous, secretOrPublicKey can be a ... ignoreExpiration : if true do not validate the expiration of the token.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Forgive my words if the opinion is too strong, but to the best of my knowledge the consensus is already there for decades.
The nature of an asynchronous API should behave like it means, implementation should be hidden behind the API even if it is a so-called lie.
The API is the contract of behavior between the library and its users, and should be followed the moment it goes public as (Asynchronous) ….
IMO #302 should in fact use the (Synchronous) … version without callback for the desired performance gain, and such performance differences should be documented instead of breaking the API.
We might be able to use something like threads.js to do this in a real multi-threaded manner, which would be fun and sexy for everyone. But it also might reduce compatibility and/or require pseudo-polyfills like webworker-fallback