Arminta
/
watermanagement-backend-prod
6
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'b0b2e7beac'
${ noResults }
watermanagement-backend-prod/node_modules/jsonwebtoken/CHANGELOG.md

5.3 KiB
Raw Blame History

Change Log

All notable changes to this project will be documented in this file starting from version v4.0.0. This project adheres to Semantic Versioning.

[5.0.0] - 2015-04-11

Changed

  • [sign] Only set defautl iat if the user does not specify that argument.

e900282a8d 35036b188b 954bd7a312 24a370080e a77df6d49d

Security

  • [verify] Update to jws@^3.0.0 and renaming header.alg mismatch exception to invalid algorithm and adding more mismatch tests.

As jws@3.0.0 changed the verify method signature to be jws.verify(signature, algorithm, secretOrKey), the token header must be decoded first in order to make sure that the alg field matches one of the allowed options.algorithms. After that, the now validated header.alg is passed to jws.verify

As the order of steps has changed, the error that was thrown when the JWT was invalid is no longer the jws one:

{ [Error: Invalid token: no header in signature 'a.b.c'] code: 'MISSING_HEADER', signature: 'a.b.c' }

That old error (removed from jws) has been replaced by a JsonWebTokenError with message invalid token.

Important: versions >= 4.2.2 this library are safe to use but we decided to deprecate everything < 5.0.0 to prevent security warnings from library node-jws when doing npm install.

634b8ed0ff 9f24ffd579 19e6cc6a1f 1e46234201 954bd7a312 24a370080e a77df6d49d

[4.2.2] - 2015-03-26

Fixed

  • [asymmetric-keys] Fix verify for RSAPublicKey formated keys (jfromaniello - awlayton) 402794663b 8df6aabbc7

[4.2.1] - 2015-03-17

Fixed

[4.2.0] - 2015-03-16

Security

  • [asymmetric-keys] Making sure a token signed with an asymmetric key will be verified using a asymmetric key. When the verification part was expecting a token digitally signed with an asymmetric key (RS/ES family) of algorithms an attacker could send a token signed with a symmetric algorithm (HS* family).

The issue was caused because the same signature was used to verify both type of tokens (verify method parameter: secretOrPublicKey).

This change adds a new parameter to the verify called algorithms. This can be used to specify a list of supported algorithms, but the default value depends on the secret used: if the secretOrPublicKey contains the string BEGIN CERTIFICATE the default is [ 'RS256','RS384','RS512','ES256','ES384','ES512' ] otherwise is [ 'HS256','HS384','HS512' ]. (jfromaniello) c2bf7b2cd7 1bb584bc38

[4.1.0] - 2015-03-10

Changed

  • Assume the payload is JSON even when there is no typ property. 5290db1

[4.0.0] - 2015-03-06

Changed

  • The default encoding is now utf8 instead of binary. 92d33bd
  • Add encoding as a new option to sign. 1fc385e
  • Add ignoreExpiration to verify. 8d4da27
  • Add expiresInSeconds to sign. dd156cc

Fixed

  • Fix wrong error message when the audience doesn't match. 44e3c8d
  • Fix wrong error message when the issuer doesn't match. 44e3c8d
  • Fix wrong iat and exp values when signing with noTimestamp. 331b7bc