Copy authorization from request to proxy

[jeffrson]

Hi,
I have a private registry, publicly accessible, but requires user account credentials.

Now I'm setting up another registry, which should use my private registry (this is in a company which usually has all clients protected, but allows access from a special endpoint to the outside). This second registry of course needs to authenticate against the former private registry.

How can this be done? I know, in "Uplinks" there are "auth" settings. These settings work fine. Unfortunately, I set up my logins to expire after about 3 months, so I would need to update the auth token (locally in this company) and restart Verdaccio. A lot may go wrong here.

Any better idea? Real copy of auth request (bearer and basic) will probably not work, because every instance has its own key for signing afaict.

[flonou]

I have the same kind of request (also evoked in discussion #3505)
In my case, I would like to have 2 verdaccio instances.
An internal one, accessible only from our network
An external one, accessible everywhere.
The external one would only list some packages available on the internal one, using the uplink/proxy feature to forward the request
My issue is that some package require to be authenticated to access (more specifically, I use the auth-gitlab plugin for this), but it seems like authentication is not forwarded to the internal instance

[juanpicado]

I will give some thoughts on this, right now forward auth token is not implemented because security reasons, :) you wouldn't want npmjs getting all your tokens, so something in the config might be need it to be done to only forward specifically registry you have control, now I have a question for both of you, who the configuration would looks like ? any ideas?

[flonou]

I Understand the security reasons and as such, I think forwarding auth tokens must be explicit in the configuration file and maybe require https uplink ?

uplinks:
  my_main_repository:
    url: https://my_main_repo.com
    can_forward_auth_token: true

packages:
  'com.myscope':
    access: $all
    publish: $anonymous $authenticated
    proxy: my_main_repository

Would something like this make sense ?
I was wondering if the token forwarding must be explicit in the proxy parameter too or not

[juanpicado]

Thanks for the idea @flonou , the last weeks I've been refactoring the proxy part I'll consider positively your feature can_forward_auth_token and I let you know how can I fit it so can be used in v5.x versions as well. Keep you posted.

[flonou]

Hi @juanpicado, is there any update regarding this ?

[juanpicado]

yes, few weeks ago I merged #3960 which is the first step to give support that feature (or any further change on uplinks) on branch 6.x , so now I can actually implement it, but won't be until next month when I intent to release 6.x and that feature would be a nice addition.

[flonou]

Nice ! thanks for the update !

[flonou]

Hi @juanpicado any news on this feature ? Is it something we could expect in an upcoming version ? Thanks !

[juanpicado]

Thanks for reminder :) I totally forgot and I was looking for missing tickets, I'll include it to v6.x

To follow up updates you can install this
https://github.com/orgs/verdaccio/discussions/4018#discussioncomment-8036037

I'll share here when is testable.

[juanpicado]

thinking on the configuration I want to make it clear this setting is not something should be broadly used. Furthermore will print a warning on the console that mentions it is enabled for X upstream and is not considered a good practice.

Also has to be mentioned that any other token configuration on each upstream will be ignored, could be the case one forgot remove previous tokens in order to use this new setup.

thoughts? insecure_forward_token

uplinks:
  my_main_repository:
    url: https://my_main_repo.com
    insecure_forward_token: true

[flonou]

I guess it makes it clear that it's insecure. Another (or additional) option, would be to require to configure this on both the uplink (as in your example) AND on the proxy parameter of each package using this uplink to make it work ?

[juanpicado]

I guess it makes it clear that it's insecure. Another (or additional) option, would be to require to configure this on both the uplink (as in your example) AND on the proxy parameter of each package using this uplink to make it work ?

Mmmm in theory would be only in the uplinks, why would be on the package access section? Maybe you see something I didn't.

[flonou]

Having it in the uplinks only is most likely enough.
My idea was that it would force the user to explicitly state that the token forward must occur on some packages too.
That way, to have a token forwarded, you need to enable it on the uplink, and activate it on the proxy setting too as a safeguard.
Maybe It might be too many options and too complicated.
I was mainly thinking in terms of reducing involuntary token forwarding.