-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nuget.exe ignores packageSourceCredentials in nuget.config when downloading a package #8551
Comments
Hey @ilatypov Thanks for the detailed issue. Apologies for the late response, I hope you were able to figure out the solution here. The biggest takeaway is that NuGet is not correlating the source and credentials. Unfortunately I was not able to reproduce this with config provided. At some point we had #7516. Does your source name have spaces? Thanks. |
I suspect that
|
Each request to a server is treated individually. You pointing out that it's the packages endpoint that's failings makes me think that it might be related to: #2869 since they both use the same underlying infrastructure. |
I am encountering the same issue right now. AFAIK the problem scenario matches the one described by @ilatypov and i created a minimal setup where I have setup a The One DIFFERENCE though: when calling curl with no credentials at all, I get a My version setup:
I'll also try to get some feedback from the JFrog guys regarding this. |
SOLVED at least for me: you need to enable "Force Authentication" on the protected nuget feeds in Artifactory. Here's the StackOverflow reference that solved it for me. |
Our poorly coded pipeline uploaded public xunit packages to a local (password-protected) jFrog artifactory. Attempts to download them using nuget.exe's packageSourceCredentials with a clear-text (encrypted) jFrog user name and password failed showing 403 Forbidden messages. Proxying the traffic through BURP showed that nuget.exe ignored the credentials supplied in nuget.config.
Details about Problem
NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe):
nuget.exe
NuGet version (x.x.x.xxx):
4.9.4.5839 and 5.2.0.6090
VS version (if appropriate):
2019 Enterprise with both the above Nuget.exe versions and 2017 (15.0) with Nuget 4.9.4
OS version (i.e. win10 v1607 (14393.321)):
Worked before? If so, with which NuGet version:
it did a day ago but stopped (I installed a dotnet 4.7 devpack using choco in between)
.Detailed repro steps so we can see the same problem
Run CMD as an administrator (after logging in as a local user). Change to a top-level directory of the drive to work around nuget.exe's failure to handle long file names. (Alternatively, set
repositoryPath
tod:\packages
innuget.config
and create a cmd symlink usingmklink /d
frompackages
tod:\packages
to resolve hard-coded relative links in the Visual Studio solution). Set up a BURP proxy in Internet Options, install the BURP cert into the Certification Authorities store.Create a
nuget.config
, delete othernuget.config
's such as%userprofile%\appdata\nuget\nuget.config
, purge the cached and installed packages.Set up a password-protected local repo in a jFrog artifactory, upload an external package such as xunit console runner 2.3.1 into it (to reproduce mistakes in pipelines). Set up a virtual repo that includes both the local repo and the remote one (Microsoft gallery). This results in artifactory allowing anonymous FindByPackageIds() calls but requiring authentication to download the above public package (xunit console runner).
Confirm the setup with curl.
packages.config
.nuget restore
with the creatednuget.config
and verbose diagnostics.The text was updated successfully, but these errors were encountered: