Web ui always shows no packages but publish and install works

[jorenl]

Hi,

I deployed verdaccio's base docker image to a Google Cloud Run container. I mounted /verdaccio/conf and /verdaccio/storage to a Google Cloud Storage (GCS) bucket.

This is my config.yaml:

storage: /verdaccio/storage/data
plugins: /verdaccio/plugins

web:
  title: Verdaccio
  darkMode: true
  scope: "@myscope"

auth:
  htpasswd:
    file: /verdaccio/storage/htpasswd
    max_users: -1

uplinks:
  # (JL) disable npmjs uplink, we want to use verdaccio for private packages only

packages:
  "@myscope/*":
    access: $authenticated
    publish: $authenticated
    unpublish: $authenticated

  "**":
    access: $authenticated
    publish: $authenticated
    unpublish: $authenticated

server:
  keepAliveTimeout: 60
middlewares:
  audit:
    enabled: true

log: { type: stdout, format: pretty, level: http }

I also configured the env variable VERDACCIO_PUBLIC_URL to https://pkg.mydomain.io.

So far, everything seems to be working great:

• I can configure my URL as repository for @myscope in .npmrc
• I can publish packages with npm publish, they appear in in the /storage/data/@myscope folder in GCS and in my /.verdaccio-db.json file:

{"list":["@myscope/nest-migrations","@myscope/nest-events"],"secret":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}

• I can install these packages elsewhere with npm install
• I can open the web UI
• I can sign in

However, the web UI keeps saying "No Package Published Yet". This is the case immediately after publishing, and after a container restart.

The GET /-/verdaccio/data/packages call returns [].

The container logs don't indicate anything going wrong:

2025-08-18 10:44:16.588 CEST
info <-- 123.123.123.123 requested 'GET /-/verdaccio/data/packages'
2025-08-18 10:44:16.588 CEST
http <-- 200, user: null(123.123.123.123 via 123.123.123.123), req: 'GET /-/verdaccio/data/packages', bytes: 0/0
2025-08-18 10:44:16.588 CEST
http <-- 200, user: null(123.123.123.123 via 123.123.123.123), req: 'GET /-/verdaccio/data/packages', bytes: 0/3

I did some digging through the in the source code for that /packages endpoint and the get() and init() methods of the local storage plug in which I believe should return and actually read the data from the json file, respectively.

From this, a couple questions:

• Maybe I am missing some security related configuration, causing the packages to be filtered out before returning them to the client?
• Maybe the "mounted filesystem" is causing a bug in the storage code. Has anyone else run into this? Anything that helped? These issues look related, but I don't see a resolution:
  • https://github.com/orgs/verdaccio/discussions/3173
  • the published packages disappeared #2390
• I see a lot of debug logs in the code. I'll retry with debug logging enabled, and see if I learn anything. But any pointers would be highly appreciated :)

EDIT: This appears to be an authentication issue. If I set access: $all everything works. Then I tried logging in in the web UI with access: $authenticated and trace logging enabled. Form the client side, everything looks good:

• First a request is made to POST https://pkg.mydomain.io/-/verdaccio/sec/login with my username,password. This succeed and returns:

{
    "token": "xxxxxxxxxxxxx",
    "username": "joren.lauwers"
}

• Then the request to GET https://pkg.mydomain.io/-/verdaccio/data/packages is made, with that exact token passed as the header Authorization: Bearer [token].
• However, in the verdaccio container, this is logged as an unauthenticated request:

2025-08-18 12:20:17.494 CEST POST 200 843 B268 msChrome 139 https://pkg.mydomain.io/-/verdaccio/sec/login
2025-08-18 12:20:17.801 CEST GET 200 438 B11 msChrome 139 https://pkg.mydomain.io/-/verdaccio/data/packages
2025-08-18 12:20:17.887 CEST info <-- 123.123.123.123 requested 'POST /-/verdaccio/sec/login'
2025-08-18 12:20:17.887 CEST http <-- 200, user: null(111.111.111.111 via 123.123.123.123), req: 'POST /-/verdaccio/sec/login', bytes: 61/0
2025-08-18 12:20:17.887 CEST http <-- 200, user: joren.lauwers(111.111.111.111 via 123.123.123.123), req: 'POST /-/verdaccio/sec/login', bytes: 61/381
2025-08-18 12:20:17.887 CEST info <-- 123.123.123.123 requested 'GET /-/verdaccio/data/packages'
2025-08-18 12:20:17.887 CEST http <-- 200, user: null(111.111.111.111 via 123.123.123.123), req: 'GET /-/verdaccio/data/packages', bytes: 0/0
2025-08-18 12:20:17.887 CEST trace--- [auth/allow_action]: user: undefined
2025-08-18 12:20:17.887 CEST trace--- [auth/allow_action]: hasPermission? false for user: undefined, package: @myscope/nest-migrations
2025-08-18 12:20:17.887 CEST trace--- [auth/allow_action]: user: undefined
2025-08-18 12:20:17.887 CEST trace--- [auth/allow_action]: hasPermission? false for user: undefined, package: @myscope/nest-events
2025-08-18 12:20:17.887 CEST http <-- 200, user: null(111.111.111.111 via 123.123.123.123), req: 'GET /-/verdaccio/data/packages', bytes: 0/3

• currently looking into if anything is interfering with authentication :)

EDIT2 (solved): After many hours of sleuthing, enabling debug logs with DEBUG=verdaccio:*, I found debug logs indicating that my JWT auth token from my web request was being validated by authentication middleware for the api which was expecting a legacy token. I fixed my installation by enabling JWT authentication for the API by adding the following to config.yaml:

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

But it looks like applying the API validation, which has separate configuration, for a request originating from the web UI would be a bug?

[mbtools]

You're analysis is right on. It's a known issue/bug: #5281 (see my comment). @juanpicado has it on his agenda already.

[juanpicado]

Working on it, slowly but surely working....