Group Details Private

administrators

  • RE: File download with wget only works with auth-no-challenge argument

    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

    posted in Support
  • RE: BuildMaster fails to return TeamCity build configs

    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

    posted in Support
  • RE: Docker Migration from Nexus – Feature Not Working

    Hi @koksime-yap_5909,

    No problem! Happy to help!

    Thanks,
    Rich

    posted in Support
  • RE: ProGet 2025.14 (Build 12) - PostgreSQL Error when uploading

    Hi @it_9582,

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

    Thanks,
    Alana

    posted in Support
  • RE: ProGet configuration as code (IaC)?

    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

    posted in Support
  • RE: ProGet 2025.14 (Build 12) - PostgreSQL Error when uploading

    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

    posted in Support
  • RE: The hostname could not be parsed

    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

    posted in Support
  • RE: License not found in package

    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

    posted in Support
  • RE: ProGet 2025.14 (Build 12) - PostgreSQL Error when uploading

    Hi @it_9582 ,

    I'm afraid this is a long-standing (since we first introduced the feature) limitation on the name. It's not changeable/configurable and would require a nontrivial code change to lengthen.

    Thanks,
    Alana

    posted in Support
  • RE: 401 When trying to download assests from private repo

    Hi @spencer-seebald_1146 ,

    I was able to identify the issue.

    When you visit the URL in ProGet, then ProGet will visit this URL (slightly trimmed) with the appropriate authorization header:

    https://libraries.cgr.dev/javascript/..../lodash/-/lodash-4.17.20.tgz
    

    However, that URL will issue a 307 redirect to the following:

    /artifacts-downloads/javascript/namespaces/15f7d141c3b76b85/repositories/.../downloads/ABmYrfCH......KpxO1ducu3xmMRtw==
    

    ProGet then follows the redirect, but does not send the authorization header. And thus, a 401 is issued. This is actually the default/expected behavior in HttpClient (i.e. the library in .NET we use) and most clients in other languages (Java, Go, Ruby, etc.) as well.

    Of course it can be worked-around by disabling auto-redirect and implementing yourself to follow the URl with the same header. But that's not so common and, as such, it's not a common practice for servers to issue redirects that require authentication; we see other services handle the redirect using some kind of token in the querystring.

    On our end, this has not been an issue to date. This is logic is buried pretty deep and it's not an easy fix without changing code everything relies on. I'm kind of surprised npm and pip override the default behavior in the fetch() and requests libraries.

    Anyway, it sounds like you can make a change on the private repository server code... so I would here would be to just disable authentication on your artifacts-downloads endpoint. I mean that URL is basically authenticated anyway.... it's so long (I stripped like 1000 characters) that it's basically a password.

    Thanks,
    Alana

    posted in Support