I pulled the ci.4 image and that fixed the issue. I haven't noticed any other issues, so I'll just leave the ci version installed until the next ProGet release. Thanks again for the quick fix.

Thanks for the reply, this is exactly what I was looking for! I guess the piece I was missing was that there were additional permission options that aren't exposed by default, but that I could bring in by adding a new task. The links you provided helped me fill in those gaps, so thanks again for that!

@atripp Thanks for the clarification, you have me pointed to the tooling and steps I will need to perform the bulk import. I will have to try, but I think I have enough information to script this task.

Any updates on this? I encounter the same issue and none of your comments helped .

You got it working though :)

That's awesome, thanks!

Hello Adam, I've filed PG-1409 to allow setting a password on a connector with a blank username, which will allow bearer tokens to be used in npm.

Have you considered to use an external connector ? See the details here : https://inedo.com/support/documentation/proget/core-concepts/feeds/connectors If impossible you would have to download and compile and them to your feed.

You need to create an API in the ProGet UI; API Access and API keys

The problem was our proxy. npm doesn't use the proxy exceptions that are configured in the system, so after updating them to include the ProGet server domain it works as expected.

The tracking issue for this is here: PG-1309

This will be fixed in PG-1273 for the next maintenance release.

Hi, I have tested with npm and all is working now. Thanks very much. Regards Fabrice

It was my reverse proxy (apache). I had to set AllowEncodedSlashes to On. Problem solved.

Hello Tobias, PG-1270 will make local packages appear before remote packages in the list, as well as making connector packages appear in the same order that they would appear in the connector.

yes, after subscribing to one of our vulnerability providers like Sona OSSIndex or Whitesource (more coming later).

It's a "401" error, which means "not authorized" In this case, you could have the wrong credentials in Yarn (or no credentials). Note that "Windows Integrated Auth" is not supported by npm or yarn.

Good question. Regarding Vor Security, that was a recent acquisition by Sonatype, and it's being transitioned into a new service called OssIndex. Sonatype plans to keep this going for the foreseeable future, and we have verified this with Ken Duck (formerly of Vor Security, now Sonatype employee). ProGet will continue to support it (we are renaming it as well). Moreover, we are planning to work with Sonatype to better integrate their broader services (vulnerability scanning) with ProGet. We are also investigating Blackduck integration, though we're not entirely sure how it would work with ProGet. Regarding "developing our own"... broadly speaking, there are two types of vulnerabilities scanning: static analysis - analyzing actual code or binaries to look for patterns (buffer overflow, etc); this is done "on your own software" repository/database - looking at public databases like NVD, CVE, etc. for vendor- or third-party documented vulnerabilities reported for a known, published piece of software We don't believe that static analysis has a place in a package manger; there are a handful of tools that can scan your codebase directly for this. As for repository/databases, it's not really bout "finding" vulnerabilities in software, it's more about "aggregating databases" and then translating those into machine-readable formats. This is what Sonatype, Whitesource, etc., do, and we think more vendors will continue to innovate in this space. But the "repository" and "scanning" are two different problems, and you should pick the best of both problems; it would almost be like saying "Microsoft makes Office, may as well use Visual Studio and .NET". ProGet has the extensibility support for this already, so we should be able to integrate with new providers as they come up,

Unfortunately it's impossible to say. The error message you have provided is in complete, and doesn't give any information about the problem. Scoped packages works in testing, and we haven't heard issues from othere users about it. You'll need to do some further debugging and provide some more information for us to further help you.

Because of a reinstall of proget with an existing database the package paths were resetted to default. After fixing the paths, the error went away. The error should be more descriptive when the files can't be found on file store.