verdaccio: "Download tarball" gives an error ("error: authorization required to access package") when authenticated

When browsing the registry with Verdaccio’s webui and logged in with an authenticated account, the “Download tarball” link does not works and I get an HTTP 401 errror with the following message:

{
  "error": "authorization required to access package @acme/acme-foo"
}

However, the access with npm (and a logged in user) works correctly.

Here is the server log for npm install @acme/acme-corp:

  debug--- [local-storage/readTarball] read a tarball for package: acme-foo-1.2.0-RC.2019.1.3.tgz
  http <-- 200, user: client01(192.168.251.209), req: 'GET /@acme%2facme-foo/-/acme-foo-1.2.0-RC.2019.1.3.tgz', bytes: 0/48585

And here is the log when accessing the package with the webui and logged with user client01:

  info <-- 192.168.251.209 requested 'GET /@acme%2facme-foo/-/acme-foo-1.2.0-RC.2019.1.3.tgz'
  http <-- 401, user: null(192.168.251.209), req: 'GET /@acme%2facme-foo/-/acme-foo-1.2.0-RC.2019.1.3.tgz', error: authorization required to access package @acme/acme-foo

The HTTP request made by the webui seems to correctly have the Authorization: Bearer <token> header but the server log does not reports the request as being authenticated with user client01 and reports the user as null.

I’m using the htpasswd authentication plugin:

auth:
    htpasswd:
        file: data/conf/htpasswd
        max_users: -1

Here is the content of my packages: access control directive:

packages:
    '@acme/*':
        access: $authenticated
        publish: admin

If I set access: $all, then the “download tarball” link works in the webui.

I tried this on verdaccio v4.0.1 and v4.3.3, and both reports a HTTP 401 when downloading the package with the “Download tarball” link.

Does anyone else also noticed this error

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 8
Comments: 31 (11 by maintainers)

Most upvoted comments

I can confirm that adding security.api section with legacy: false and jwt to the config fixes the issue for me. Running 4.6.2 behind nginx reverse proxy. Thx @hdmr14 👍

krzaczek on May 2, 2020

security:
  api:
    legacy: false
    jwt:
      sign:
        expiresIn: 29d

I can confirm that just adding this block the tarball download works (tested in brave) my web configuration just has the title key

masterkain on Mar 25, 2022

Verdaccio over web support only JWT by default, legacy is not used there. But thanks 🙏 for digging I’ll double-check.

juanpicado on May 1, 2020

Ok, some news here, as @krzaczek mentioned, the tarball download don’t work when using legacy security setting. So in my config.yaml I added this section (@anselanza @masterkain):

security:
  api:
    legacy: false
    jwt:
      sign:
        expiresIn: 29d

After restarting the server, everything works fine. @juanpicado you should mention in the docs that legacy security for the api layer brakes the tarball download feature.

Sov3rain on Mar 25, 2022

finally I found how issue happens.

verdaccio/ui make request header based on server response which got when logged in successful. but server login api has no function for AES option(at user.ts:28).

When no security option specified, server makes config.security.api to legacy, but login function(also ui too) only generate JWT token. This is a cause of issue!

perhaps Verdaccio supports only JWT for now? config of verdaccio/ui specified security.api has jwt by default for test, but verdaccio/verdaccio isn’t.

Update: I confirm that can download Tarball successfully on 4.6.2 if security.api has jwt configurations. but I don’t know why it happens only on behind proxy🤔︎

hdmr14 on May 1, 2020

@hdmr14 https://registry.verdaccio.org/ here works fine (please don’t use it 😃 it is just a life-saver cache for our builds, not ready for a high workload) . I’m not sure whether the configuration used has an effect. I have a dummy package under auth and I can access correctly downloading the package via the web. The unique difference is I don’t use $authenticated rather a specific user. We use Nginx and configuration is the same as we defined in the documentation.

I also tested with all modern browsers, nothing problematic.

To explain what the null(200.x.x.x.x.x) xxxx means. The token is not going through the reverse proxy for some reason, the token is not reaching Verdaccio, thus display null and takes the request as anonymous.

If you try Verdaccio out of reverse proxy, it should work fine.

juanpicado on May 1, 2020

l’ll do that next week, I need to revert my config file, i’ll let you know.

Sov3rain on Mar 25, 2022

I’m interested in this too, I deploy on kubernetes via helm behind an nginx ingress and manual download from UI does not work. authorization required to access package

masterkain on Sep 3, 2020

So I’m not quite following what the workaround is, since I’m having the same issue…

Are we supposed to make a change in the config files under /usr/local/lib/node_modules/verdaccio/conf? If so, which file and what should be added/changed?

Or is something meant to be changed in the proxying config (e.g. nginx) ?

anselanza on May 26, 2020

In my study, the problem not appearing with simple local reverse proxy. It appeared with multi VirtualHost with each different domain name settings in my case.

I checked verdaccio internal processing, and I found curious thing that isAESLegacy returns true but scheme and token in authorizationHeader has JWT/Bearer Value. user: null happens caused by it.

Here is a head of decoded token at parseAESCredentials

{"alg":"HS256","typ":"JWT"}{"real_groups":....

This can be verified successfully by verifyJWTPayload.

I’ll continue to study how this happens.

hdmr14 on May 1, 2020

Guys, is any of you using a verdaccio behind a proxy? I’ve been checking a recent case with this issue and might be the reason, not sure yet. We have a registry behind Nginx at Verdaccio (which I update regularly) for the builds and the download after login via UI works fine.

juanpicado on May 1, 2020

I’m noticing a similar issue in #1518.

lukeify on Oct 15, 2019