Hi Alana,

thanks for the input.
Made me reconsider our current versioning scheme to a much simpler and more deterministic solution.

This topic can be marked as resolved now!

The SemVer feature for Docker Feed comes in quite handy (especially with the automatic tag creation for major versions etc.)
However we encountered a small problem wenn utilizing image from the Microsoft Container Registry (mcr.io).

Especially the base images for windows utilize a four digit scheme (x.x.x.x) to indicate os.minor.build.patch-level.
We consume these images and alter them to our needs, yet we're unable to keep the same versioning scheme and republish our alteration with the four digit scheme.

Would it be possible to weaken the SemVer validation in order to support this common versioning scheme as well?

Best regards
Simon

It seems the 401/403 only happens for NPM/NuGet calls and not on the Web UI.

If you'd like I can search for the corresponding log messages and get them to you for further troubleshooting.
However, with the appropriate DB sizing the issue is mostly non-existent (once every few days) which is totally tolerable.

Cheers
Simon

@atripp it seems that the Problem was mostly temporary and ist resolved now.
For now we're using just the built-in authentication provider.

However another interesting behavior we noticed in our current instance:

When some Database transactions fail (especially during the login procedure) ProGet returns 401 and logs a SQL error in the Diagnostics Center.
It may be the case, that something similar happened with the 403 problem, since we had to size-up our database quite significantly!

Is this a desired behavior or shouldn't proget return something like 500/504 etc. when the database connection fails? 401 normally indicates invalid credentials and not overload on the server.

Cheers, Simon

@atripp afaik, there is no other authentication in front of the proget. we're simply using the built-in basic auth scheme.
interestingly, it only happens from time to time. If you re-run the npm install oder dotnet restore it typically find the package it returned 403 from.

Maybe some weird overload behavior is taking place there?

Hi,

we've recently setup our new Artifact Feed based on ProGet.
The feed is hosted using Azure Container Instances and publicly accessible.

We've configured 6 separate feeds, both an unapproved and approved one for npm, nuget and docker.
License filtering is enabled, but only blocks GPL-kinda licenses, which we don't use in any of our dependencies!

When connecting to our service we encounter some very weird behavior:

1. Most packages can be downloaded without any problem (when utilizing npm install specifically)
2. In our automation, some packages return 403, even though their perfectly accessible in the web UI or when installed/downloaded manually. However, this problem only happens occasionally and the pipeline works most of the time.

The 403 does not appear in the API access log, which makes this behavior even more weird.

Is there any kind of automatic rate limiting in ProGet?

Best regards