Token authentification via proxy socket

Trying to set up a nodejs/npm registry server with this GitHub - verdaccio/verdaccio: 📦🔐 A lightweight Node.js private proxy registry

It all works fine served direct on local machine without caddy. It uses a token (JWT?) to authenticate through a socket to server for allowing publishing.

Now I set up another instance on my server and here is my caddy file entry. {
       import wildcard_cert
       proxy / localhost:4873 {

I had to add the websocket and transparent to get the webpage to come up and cli access to function.
It works. I can “add user” via command line and it gives me a token that is read when any command line publishing is done.

Only the authentication fails when run through Caddy.

Is there something else I need in my caddy entry? Do I need to use another plugin? JWT?
Obviously the proxy is messing up the authentication handshake. I just don’t know how to remedy that.

here is log of communication with server showing the authentication failing.

verbose mapToRegistry no registry URL found in name for scope @uci
22 silly mapToRegistry using default registry
23 silly mapToRegistry registry
24 silly mapToRegistry data { type: 'tag',
24 silly mapToRegistry   registry: true,
24 silly mapToRegistry   where: undefined,
24 silly mapToRegistry   raw: '@uci/base',
24 silly mapToRegistry   name: '@uci/base',
24 silly mapToRegistry   escapedName: '@uci%2fbase',
24 silly mapToRegistry   scope: '@uci',
24 silly mapToRegistry   rawSpec: '',
24 silly mapToRegistry   saveSpec: null,
24 silly mapToRegistry   fetchSpec: 'latest',
24 silly mapToRegistry   gitRange: undefined,
24 silly mapToRegistry   gitCommittish: undefined,
24 silly mapToRegistry   hosted: undefined }
25 silly mapToRegistry uri
26 verbose publish registryBase
27 silly publish uploading /tmp/npm-22521-9940c208/tmp/fromDir-68e1f29c/package.tgz
28 verbose request uri
29 verbose request sending authorization for write operation
30 info attempt registry request try #1 at 10:06:11 PM
31 verbose request using bearer token for auth
32 verbose request id b8d3970ee1e42fc6
33 http request PUT
34 http 401
35 verbose headers { 'access-control-allow-origin': '*',
35 verbose headers   'content-length': '69',
35 verbose headers   'content-type': 'application/json; charset=utf-8',
35 verbose headers   date: 'Wed, 23 Jan 2019 06:06:11 GMT',
35 verbose headers   etag: 'W/"45-NzrHU3aghxa8hgBb908u5ufMZ8s"',
35 verbose headers   server: 'Caddy',
35 verbose headers   vary: 'Accept-Encoding',
35 verbose headers   'www-authenticate': 'Basic, Bearer',
35 verbose headers   'x-powered-by': 'verdaccio/3.10.2',
35 verbose headers   'x-status-cat': '' }
36 error publish Failed PUT 401
37 verbose stack Error: authorization required to publish package @uci/base : @uci/base
37 verbose stack     at makeError (/usr/lib/node_modules/npm/node_modules/npm-registry-client/lib/request.js:329:12)
37 verbose stack     at RegClient.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-registry-client/lib/request.js:317:14)
37 verbose stack     at Request._callback (/usr/lib/node_modules/npm/node_modules/npm-registry-client/lib/request.js:216:14)
37 verbose stack     at Request.self.callback (/usr/lib/node_modules/npm/node_modules/request/request.js:185:22)
37 verbose stack     at Request.emit (events.js:188:13)
37 verbose stack     at Request.<anonymous> (/usr/lib/node_modules/npm/node_modules/request/request.js:1161:10)
37 verbose stack     at Request.emit (events.js:188:13)
37 verbose stack     at IncomingMessage.<anonymous> (/usr/lib/node_modules/npm/node_modules/request/request.js:1083:12)
37 verbose stack     at Object.onceWrapper (events.js:276:13)
37 verbose stack     at IncomingMessage.emit (events.js:193:15)
37 verbose stack     at endReadableNT (_stream_readable.js:1129:12)
37 verbose stack     at process.internalTickCallback (internal/process/next_tick.js:72:19)
38 verbose statusCode 401
39 verbose pkgid @uci/base

here is an example token it generated. Can one tell by length maybe if it looks like a JWT?

I don’t think it’s a JWT. If I recall correctly, JWTs have three dot-delimited parts (i.e. 111111.222222.333333). It’s probably just a bearer token, I don’t think it likely that the distinction of type is important.

Can you show us what a log of your server demonstrating proper authentication handling looks like?

All good. Not caddy issue. I had it set right.

I did have the tell the server in it’s config to specifically listen to 4873

that’s probably always the first thing to try. Have server listen at and maybe use
proxy / {
instead of localhost when server is on same machine as caddy. typically means any IP address - so if it is available at localhost but doesn’t like that hostname, maybe you could try proxy to

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.