[ProGet] NPM install or NuGet restore return 403, but only for some packages

sbaeurle

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:

Most packages can be downloaded without any problem (when utilizing npm install specifically)
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

atripp

Hi @sbaeurle ,

That is strange; ProGet will issue a 403 when the request is unauthorized, meaning that authentication (name/password) was correct, but the user/key doesn't have permission. That isn't really an error that would happen intermittently on the ProGet side.

It's possible that ProGet isn't issuing a 403 error. Is there some kind of authentication in front of ProGet, on the azure side? ProGet does not log these requests, so your best bet may be to monitor traffic and see if you identify what is issuing the 403.

Best,
Alana

sbaeurle

@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?

atripp

Hi @sbaeurle ,

That's definitely strange; there's really nothing in ProGet that would cause intermittent 403s.

If you aren't doing so already, I would suggest switching to using API Keys in ProGet instead of LDAP. Make sure they are not "Personal Keys" but Feed keys. That will eliminate any potential issue with LDAP queries returning inconsistent results.

Otherwise, you'd almost need to capture those bad requests and see how they're different. ProGet does not have a means of capturing HTTP traffic, so you'd have to use something like Fiddler or Wireshark.

Cheers,
Alana

sbaeurle

@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

Hi @sbaeurle ,

I'm glad to issue is mostly resolved now!

In general, ProGet issues 500 errors when there are problems like database connections, overload, etc. We have not seen a 401 issued in a case like that. That's not to say it didn't happen to you, but that's not how ProGet will behave.

401/403 are only issued on API endpoints calls; if there's an error during authentication (like if you added an intentional bug to a procedure that checks the api key validity), then a 500 should be issued.

Cheers,
Alana

sbaeurle

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