Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Getting 401 error (Unauthorized) for DNX NuGet packages
-
Hello:
When VS 2015 is connected to nuget.org, I am able to download NuGet packages like System.Globalization, System.Reflection, System.Runtime, and Xunit. However, when connected to ProGet, I get error 401 unauthorized for these same packages. This is a SERIOUS problem.
I am using ProGet version 3.8.6. I also tried caching the xUnit package and that didn't change the error. I use the same credentials to connect to ProGet as I do to administer it.Thanks for your help in getting this resolved.
John
Product: ProGet
Version: 3.8.6
-
NuGet.org is always anonymous, but ProGet feeds can be configured for authentication.
So, in this case, you'll need to make sure that you've configured visual studio to use your ProGet credentials, and that your credentials are authorized to use that feed.
-
I experience the same issue when using ProGet enterprise with LDAP and Integrated authentication only for DNX projects (or projects which explicitly are targetting the NuGet V3 API).
I think DNX which is now renamed to dotnet cli is a use case which cannot be ignored by the ProGet team. Its bad enough that NuGet 3.0 support has been so far behind in the first place.
Can someone from inedo at least try this out and publish workarounds for there user base instead of continuously punting the issue. Its very frustrating and I am considering not renewing our ProGet subscription because of this.
-
Hi Damian,
Sorry for the difficulties, but can you be more specific?
Please understand, a lot of the challenges/issues are client related. NuGet Visual Studio Client 3.0x, 3.1.x, 3.2.x simply did not support authenticated feeds. There was nothing we can do to get around that problem; the only workaround is to disable authentication or use a different client version.
Note that in 3.3, we have heard reports of still several corner cases related to some pre-release packages where the client will not authenticate. After doing Fiddler traces, it was confirmed a client issue - and should be resolved in a future release.
Please also note that, the NuGet 3.x clients still fully support the ODATA (v2) api protocol; the protocol (ODATA vs JSON-LD) is a different abstraction layer than authentication. Unless there's some other bug we're not aware of, the only reason it works on NuGet.org and not in ProGet is because NuGet.org is anonymous, and you have ProGet configured to be authenticated.
Best,
Alana
-
So I spent quite a bit of time trying to get this to work. Finally I followed your suggestion for a different issue 4208 around getting npm feeds to work:
- I created another IIS WebSite and enabled annoymous authentication on that site.
- I pointed that site to the same ProGet installation
This seems to work with DNX.
It would be nice if inedo could provide first class support for these scenarios where a client does not support authentication for its feeds. What we want to do is provide users through LDAP and use active Directory to restrict permissions when administering ProGet and publishing packages. When it comes to consuming packages first class support for anonymous feeds with LDAP enabled would be ideal.
Until then, this is a suitable workaround (at least until it stops working).
Thanks
-
Believe me, we really wish it was feasible to provide "Integrated Windows Authentication" (i.e. 401/NTLM challenges) for some feeds, and "Anonymous" for others.
The problem is that this is implemented at the HTTP.SYS stack level (a kernel-level service), which far below IIS. NTLM/Kerberos authentication is not something we can feasibly implement ourselves... even if we did, the TGS Exchange cannot really run in a protected environment (like an app pool user).
This has been a known issue by Microsoft for at least 10 years, and they are planning to introduce some new libraries/options with Server 2016. There are rumors they will drop it altogether in favor of federated authentication (i.e. Azure style). But, it's not huge on their priority list I think.