Replies: 1 comment 2 replies
-
|
I can reproduce the issue. The storage looks correct to me and the cidr list is returned to the npm client. There seems to be some validation in the npm client that not visible even with verbose logging. This needs a deeper analysis |
Beta Was this translation helpful? Give feedback.
-
|
Found the bug. the field is called |
Beta Was this translation helpful? Give feedback.
-
|
#5186 returns the cidr list correctly to npm and it shows in Can you test if this fixes the authentication issue, too? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Meta: As requested in the bug template and because I'm not sure if this is a bug or just not fully implemented, I'm creating a discussion. Please feel free to convert to a bug or feature request.
I created a token using the
npm token create --cidr="[...]" --registry [...]command. By looking at theverdaccio-db.json, I can verify that the CIDRs have been set:However, the usage of the token seems no to be restricted to the specified CIDRs of the allowlist.
I can authenticate using the token from other IPs than the specified ones and the
npm token list --registry [...]command doesn't output any of the CIDRs:According to the official docs, the output should look like:
I'm using the containerized Verdaccio, version 6.0.5, with a freshly converted 32-bit secret and the htpasswd auth plugin.
Is this part of the token auth logic not yet implemented or is it a bug? (Or am I missing something? I don't want to rule out this possibility, of course.)
Beta Was this translation helpful? Give feedback.
All reactions