Feature: Public Web Access, Private tgz download access

[NathanaelA]

Is your feature request related to a problem? Please describe.
I would like the web interface/page to be public and show all the docs/readme's but the ability to npm install or download the .tgz directly would require the user to log in/or be logged in.

Describe the solution you'd like
Perhaps a new setting in the config for website access?

Additional context
I am going to have a private registry for certain packages; however to read the actual docs is not private -- I think it makes a lot more sense to allow them to search, read the readme's; link to the git repo from the web facing registry. The only part I need secured is the actual download of the tgz file...

[juanpicado]

hi @NathanaelA . I think this is not doable, let me explain why.

When you click download tarball you are actually downloading from the registry API, thus, if we add some sort of login for fetch tarballs this also will affect the npm installs since uses the same URL for fetch tarballs to you project. So, either you block users to access your packages open or leave them completely open, but, there is no middle ground for this.

[NathanaelA]

Actually it does appear there is a way to do it. ;-) I actually played with this a bit last night and I made only a couple quick hacks and was able to make visibility work. I haven't finished testing to make sure that install was still locked; but none of the code I changed appears to have anything to do with install. But view worked great. I added two view access items. :-)

If I got it working properly, would a view access level PR be accepted?

[juanpicado]

Perhaps you can show me a PoC, it would be great to see your approach.

[NathanaelA]

@juanpicado - Just finished testing. Yes it does work.

So far I only had to change the following:

• https://github.com/verdaccio/verdaccio/blob/master/src/lib/auth.ts#L171 -> I duplicated the allow_access to be a new function called allow_view (right now hard coded to say yes, can view, not using any config value yet, just wanted to make sure it worked).
• https://github.com/verdaccio/verdaccio/blob/master/src/api/middleware.ts#L105 - I duplicated the allow to be a view function.
• https://github.com/verdaccio/verdaccio/blob/master/src/api/web/endpoint/package.ts#L24
  Changed this to use the new allow_view function
• https://github.com/verdaccio/verdaccio/blob/master/src/api/web/endpoint/package.ts#L79
  Changed the can('access') to can('view')
• https://github.com/verdaccio/verdaccio/blob/master/src/api/web/endpoint/search.ts#L25 change this to use the allow_view function again.

Tested it. Config has $authenticated as the access value. I can view all packages; and view the readme of the package. But when I tried to do a npm i with my login removed; it failed with un-authenticated. Relogging in via npm, allowed me to do a npm i as expected..

If this is a feature you would like to add; I'll can work on adding an actual view key to the config file and actually use it for the permissions. If you aren't interested in this feature; then my hack is good enough to allow me to proceed with what I need. ;-)

[NathanaelA]

@juanpicado - You can see a version with these changes at: https://npm.proplugins.org I also was able to make a single change to the search allow_access to allow_view and it worked like the other files. So adding a "View" security is fairly trivial...

[juanpicado]

Thanks 🙏 I will take a look along the week :)

[NathanaelA]

Since you swapped to TS; I fixed all the links in my changes post; and added the single search change I had to do. View mode works perfectly as far as I can see, and the changes are pretty simple overall. ;-)

[juanpicado]

@juanpicado - Just finished testing. Yes it does work.

So far I only had to change the following:

• https://github.com/verdaccio/verdaccio/blob/master/src/lib/auth.ts#L171 -> I duplicated the allow_access to be a new function called allow_view (right now hard coded to say yes, can view, not using any config value yet, just wanted to make sure it worked).
• https://github.com/verdaccio/verdaccio/blob/master/src/api/middleware.ts#L105 - I duplicated the allow to be a view function.
• https://github.com/verdaccio/verdaccio/blob/master/src/api/web/endpoint/package.ts#L24
  Changed this to use the new allow_view function
• https://github.com/verdaccio/verdaccio/blob/master/src/api/web/endpoint/package.ts#L79
  Changed the can('access') to can('view')
• https://github.com/verdaccio/verdaccio/blob/master/src/api/web/endpoint/search.ts#L25 change this to use the allow_view function again.

Tested it. Config has $authenticated as the access value. I can view all packages; and view the readme of the package. But when I tried to do a npm i with my login removed; it failed with un-authenticated. Relogging in via npm, allowed me to do a npm i as expected..

If this is a feature you would like to add; I'll can work on adding an actual view key to the config file and actually use it for the permissions. If you aren't interested in this feature; then my hack is good enough to allow me to proceed with what I need. ;-)

Thanks @NathanaelA for your detailed explanation, here are my thoughts.

What I've seen by far is you want specific permissions for web endpoints allowing users to read the readme and access the packages (list them in the UI) using a new property in package access section named view (now hardcoded to true), while the API endpoints remains using the same authentication layer based on "access" properties in the config file which forbid access the tarball as you expected. I hope I got this right, based on your explanation and playing around in your production demo 👍

The idea to separate access roles for UI and API seems interesting to me, but I do not agree with the implementation. The differences between view and access should be global, in your proposal the scope affects only the web access, I'm afraid this will create confusions and an extra layer of complexity. It also a breaking change, since all users will need to update their config files to avoid suddenly leak readme or their packages are displayed in the UI or we'd need to do a lot of black magic behind the scenes to make it work. Not to speak about update the tests.

I have no proposal in exchange for this unless suggesting create a middleware plugin, which might work.

Hopefully you understand all my concerns.

However, I'm open to listen more options (from you or anyone) about how to address your proposal.

[NathanaelA]

@juanpicado -

1. Actually I have no issues with view access through NPM and any other cli's via the api. In fact it is better if it is consistent between the CLI's and web. ;-)

2. The only thing I want behind access is actually downloading the TGZ files, no matter where the request is coming from. So I want/need everything else to be easily publicly seen on my server.

3. We can mitigate breaking anything, if view isn't in the config view can take the exact same permissions as access. So anyone migrating would get the same behavior as before. Anyone who want to open it up a bit more would be able add a view configuration item and assign different permissions.

Thoughts?

[artemdudkin]

The idea to separate access roles for UI and API seems interesting to me

Plz show the use case. Can not imagine why people can download package via web and can not download it via CLI.

[NathanaelA]

@artemdudkin - I believe you misunderstood me. I wanted view access so that people can see all the packages, read the readme's, get the links to the repos; but CANNOT download the .tgz the via npm i AND/OR via the webpage. 😀 Does that make sense. I realize this is probably not something anyone else is doing -- but I do want the links, and readme public. I just need the authentication only for download and publish.

The changes I listed above gave me a public/everybody "view" mode with no ability to download unless they are logged in.

My Verdaccio instance is currently working this way (with these changes); and meets these needs properly. So I am good!

So, this issue can be closed now, unless you guys want to leave it open to possibly re-implement these changes in a future version.

---

Do to some additional features I was pondering today, I realized a completely different and better way for me to proceed. One which will give me the ability to easily add all the additional features that I need and will actually simplify my infrastructure as my https://plugins.nativescript.rocks/plugins codebase already has most the features I needed. So rather that add features to Verdaccio; I just need to add NPM endpoint api to my own codebase and then Verdaccio won't be needed any more. I'll have the ability to easily add any of the final missing features, and won't have to worry about backwards compatibility. 😀

Verdaccio is an awesome product -- and it got me off the ground for my next venture. However, I think I am doing something that doesn't really co-inside with what the majority of people need from it and the number of features that I would need to add/or retrofit into Verdaccio to match what I already have and what I need -- I believe a lot more work than shifting my direction... 😀

[JSC-Sparkling]

The idea to separate access roles for UI and API seems interesting to me

Plz show the use case. Can not imagine why people can download package via web and can not download it via CLI.

I have a specific usecase for this, but in reverse: people cannot view packages via web (unless authenticated), but can download them via CLI (if they know the exact url) without authentication.

The use case for this would be to allow a private (as in, private usage for our company only) npm registry to be accessible remotely (i.e. for those devs that work from home), but have the web interface locked behind authentication (so in case someone does find our url, they still need a user & pass to view the list of packages).

This is especially useful for people wanting to setup their own npm registry and use it in Unity 2018.4 LTS (a game development engine that uses most of the npm concepts to allow adding additional packages containig game assets), since users can add their own scoped registry, and put the user & pass in the url itself (https://user:[email protected]) and the Unity Package Manager can then retrieve the packages and list them in their UI. The issue comes once a package has to be installed, it reads the tarball url and attempts to download the .tgz file, but it can't, since it requires authentication and none is supplied, since the user & pass is not present in the tarball url.
Thus it would be useful to have the .tgz available without authentication, but have the package listing protected by authentication. So only those who can "guess" or "know" the exact url can obtain the package, which'll be very unlikely to guess for outsiders since they'd need to know the office server url AND the full package name AND version used to be able to obtain the package contents.