This article presents some improvements introduced in version 2 of FoalTS:
- the JWT utilities to manage secrets and RSA keys,
- the JWT utilities to manage cookies,
- and the new stateless CSRF protection.
This article is the part 3 of the series of articles What's new in version 2.0. Part 2 can be found here.
Starting from version 2, there is a standardized way to provide and retrieve JWT secrets and RSA public/private keys: the functions
In this example, a base64-encoded secret is provided in the configuration.
getSecretOrPrivateKey functions will return the secret.
In the case a
secretEncoding value is provided, the functions return a buffer which is the secret decoded with the provided encoding.
In this case,
getSecretOrPrivateKey return the keys from the environment variables
RSA_PRIVATE_KEY if they are defined or from the files
In version 2, Foal provides two dedicated functions to manage JWT with cookies. Using these functions instead of manually setting the cookie has three benefits:
- they include a CSRF protection (see section below),
- the function
setAuthCookieautomatically sets the cookie expiration based on the token expiration,
- and cookie options can be provided through the configuration.
In version 1, providing a CSRF protection was quite complex. We needed to provide another secret, generate a stateless token, manage the CSRF cookie (expiration, etc), use an additional hook, etc.
Starting from version 2, the CSRF protection is all managed by
The only thing that you have to do it to enable it through the configuration:
When it is enabled, an additional
XSRF-TOKEN cookie is sent to the client at the same time as the auth cookie (containing your JWT). It contains a stateless CSRF token which is signed and has the same expiration date as your JWT.
When a request is made to the server, the
@JWTRequired hooks expects you to include its value in the
Stay up to date with the newsletter.