inedo-engineer

Hi @it_9582 ,

Thanks for the additional information.

The reason this is happening is because these endpoints do not return a WWW-Authenticate: Basic ... header value when responding with 401.

This behavior intentional, as our preferred authentication is using an API Key header value, not Basic credentials. Basic is an alternative option and can be used when you can't easily pass a header.

We are not willing/able to change this behavior, as it would require changing code on a substantial number of endpoints and may break user integrations that have been relying on existing behavior.

So I'm afraid this means you'll need to do one of the following:

• add the --auth-no-challenge option
• use wget --header="X-ApiKey: <api-key>" "<Download path>" instead
• use curl instead
• use pgutil instead

Cheers,
Alana

Hi @aristo_4359 ,

I assume you are referring to npm packages? And that you are using the /packages page and not the Feed page?

This behavior seems a bit quirky, but expected. The /packages page does not have any special logic for handling package-specific types - and the "search" is more like a "filter". In npm, the @ symbol denotes a group (namespace), and the / symbol is the separator between a group and name - and this is why you get this behavior.

Hope that explains the behavior a bit! It's not ideal, but a limitation for performance, etc.

Cheers,
Alana

Hi @it_9582 ,

Unfortunately I'm not really sure what your script is doing or how to fix it... but I will describe the server (ProGet) behavior.

Unless you allow Anonymous access on the endpoint, ProGet will respond with a 401 when you access a URL without any authentication information (API Key header, Basic credentials). That's what the message you are sharing appears to do.

So if you're getting that message, then I guess the username/password isn't being sent? I really don't know what --auth-no-challenge means or does.

Thanks,
Alana

Hi @kquinn_2909

That is why you are not seeing the builds. That build types API is returning the Id as WebProjectsReplicatorBuildOnChange, where the builds API is returning WebProjects_Replicator_BuildOnChange as the Id. Are you using any sort of shared build type?

Thanks,
Rich

Hi @koksime-yap_5909,

No problem! Happy to help!

Thanks,
Rich

Hi @it_9582,

I'm afraid this requires a code change and an external database will have no impact.

Thanks,
Alana

Hi @mikael ,

We have no plans for this and honestly, I wouldn't recommend setting up a tool like ProGet in this manner.

Outside of some very specialized use cases (like setting up labs for testing, or nodes in a ProGet Enterprise Edge Computing Edition) there are no benefits. Only headaches.

It might sound fine on paper, but every company that has set it up this way has regretted it. And you will to. The reasons they want "fully reproducible configuration" is usually:

• so we can store configuration in versioned code
• so we can easily replicate it in a testing environment
• so we can easily migrate/move to a new server

Those seem nice, but it totally fails in practice.

First, you can't "rollback" most configuration. Say you fat-finger a configuration file and delete half your feeds. There go all your packages. And when you realize you've got gigabytes/terabytes of content to deal with, plus all the metadata in storage, this is a huge headache.

The configuration you can make idempotent (say, permissions/users) is so much more a pain to work with than a UI. Again, more error prone you lose all the benefits of visual cues, input verification, etc. You fat-finger the wrong setting, and you get some obscure error instead of a helpful red box next to the text box.

The regret comes in realizing they've created a buggier environment that isn't properly tested, and is somehow less "portable" than an ordinary installation. A year later, when the new team comes in, they usually have to figure out how to "undo" it -- and you can probably guess why we need to get involved to untangle the mess.

Thank,
Alana

Hi @it_9582,

It's certainly possible :)

However, given the risk associated with the change, it could only happen in a Major Release. This would require editing a lot of code and trying to track down everywhere we might have trimmed/restricted to 200 characters.

I can add it this to our roadmap for consideration, but note that ProGet 2026 hasn't been targeted for a date yet, let decided what features we'll do.

I just want to be realistic about the timeline - let us know if you'd like to consider it. It hasn't come up in the very very many years this feature existed, so we're not even totally sure if we'll do it (if it's too much code / too much risk / too close to the deadline / etc).

Thanks,
Alana

Hi @Julian-huebner_9077,

This error is occurring while ProGet is trying to generate the "base url". There are a few inputs that go into this:

• Admin > Advanced Settings > Base URL
• X-Forwarded Headers, set by a reverse proxy like ngnix

If any of those have an invalid host name (which is what the error is indicating), then you'll get this error. In most cases, it's a typo in the X-forwarded headers.

Thanks,
Alana

Hi @dwynn_6489 ,

I was able to reproduce this issue; the issue is that the package's license declaration specifies a license file of package/license.txt, but that file does not exist in the package.

We will improve this error message via PG-3199 in the upcoming maintenance release, but in the meantime, the only workaround is to manually assign the license under SCA Licenses. The new version of ProGet will include a direct link to that page for convenience.

The Purl you'd need to add is as follows:

pkg:npm/%40progress/kendo-charts@2.9.0

Hope that helps,
Alana