You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The JWT verify options specified in the config file do not appear to be respected. Sign options are respected.
For example, in the following config, tokens signed more than one day ago will be rejected due to being expired despite ignoreExpiration being set to true.
Based on my testing, this appears to be the case for all verify options, not just ignoreExpiration.
To Reproduce
Create a Verdaccio configuration using JWTs for security, with
a. expiresIn set (i.e. 1m) under sign options
b. ignoreExpiration set to true under verify options
Start the server and authenticate a user to retrieve their token
Before expiresIn, use the token from step 2 to access the registry and verify that it is valid
After expiresIn, attempt to use the token from step 2 to access the registry and observe that it is rejected despite ignoreExpiration being set
Expected behavior
Relating to the above example, the token should not be rejected despite being expired.
More specifically, all verify options should be respected as defined in the config file.
# This is the config file used for the docker images.# It allows all users to do anything, so don't use it on production systems.## Do not configure host and port under `listen` in this file# as it will be ignored when using docker.# see https://github.com/verdaccio/verdaccio/blob/master/docs/docker.md#docker-and-custom-port-configuration## Look here for more config file examples:# https://github.com/verdaccio/verdaccio/tree/master/conf## path to a directory with all packagesstorage: /verdaccio/storage/datamax_body_size: 200mbweb:
# WebUI is enabled as default, if you want disable it, just uncomment this line#enable: falsetitle: Verdacciomiddlewares:
github-oauth-ui:
enabled: trueaudit:
enabled: trueauth:
github-oauth-ui:
org: my-orgclient-id: ${githubClientId}client-secret: ${githubClientSecret}token: ${githubToken}# a list of other known repositories we can talk touplinks:
npmjs:
url: https://registry.yarnpkg.com/cache: truemaxage: 2hagent_options:
keepAlive: truemaxSockets: 40maxFreeSockets: 10packages:
'**':
access: $authenticatedpublish: $authenticatedunpublish: $authenticatedproxy: npmjs# This block enables download of Tarball from the UI# Refer: https://github.com/verdaccio/verdaccio/issues/1508#issuecomment-622867971security:
api:
legacy: falsejwt:
sign:
expiresIn: 365dverify:
ignoreExpiration: trueweb:
sign:
expiresIn: 365dverify:
ignoreExpiration: true# Required since verdaccio 5.4.0 as default is 0 and incompatible with verdaccio-github-oauth-ui plugin# Refer: https://githubplus.com/n4bb12/verdaccio-github-oauth-ui/issuesuser_agent: true# log settingslogs: {type: stdout, format: json, level: http}# logs: {type: file, path: verdaccio.log, level: info}
Environment information
Running in a docker container in a kubernetes cluster.
Your Environment
Describe the bug
The JWT verify options specified in the config file do not appear to be respected. Sign options are respected.
For example, in the following config, tokens signed more than one day ago will be rejected due to being expired despite
ignoreExpiration
being set totrue
.Based on my testing, this appears to be the case for all verify options, not just
ignoreExpiration
.To Reproduce
a.
expiresIn
set (i.e.1m
) under sign optionsb.
ignoreExpiration
set totrue
under verify optionsexpiresIn
, use the token from step 2 to access the registry and verify that it is validexpiresIn
, attempt to use the token from step 2 to access the registry and observe that it is rejected despiteignoreExpiration
being setExpected behavior
Relating to the above example, the token should not be rejected despite being expired.
More specifically, all verify options should be respected as defined in the config file.
Configuration File (cat ~/.config/verdaccio/config.yaml)
Environment information
Running in a docker container in a kubernetes cluster.
The text was updated successfully, but these errors were encountered: