I am currently configuring a couple of Nuget feeds in ProGet. I decided to activate feed security which uses the standard forms authentication.
To prevent Visual Studio from asking, I added to NuGet.config the proper credentials for both sources. With this in place I tried downloading a package, and what I found was that Nuget VS extension while it could list and filter all packages in the feed, when
asked to install any, it would pop up the credentials prompt repeatedly, ignoring any written.
After debugging the extension I found two problematic points. What I would like to know is whether these 2 points are quirks that don't have a good fix or I am missing something.
1) Credentials don't flow to package download requests if the registered feed url is not a prefix.
ProGet defines a main feed url of the form
>. All listing actions use this url. But package download use urls of this form
http://<server>/api/v2/package/<feed-name>/<package-name>/<version>, which doesn't have the feed url as prefix
Nuget retrieves the credentials written in Nuget.config based on url equality (NuGet.SettingsCredentialProvider.TryGetCredentials), which works for the first url (and explains why listing works in my case). But then it stores the credentials in an instance
of CredentialCache, which only works when the associated url is a prefix of the requested url (and so download urls fail to authenticate).
After this failure it asks the credentials to the user and then caches them. If the credentials are accepted by the server (which in my case weren't) then they get cached and everything will work from that point on.
But shouldn't it be possible to flow the credentials automatically? The link between both url structures seems pretty fixed in ProGet. Perhaps defining patterns that can associate a url to the base feed.
2) The credential returned by IVsWebProxy has an extraneous domain.
After failing to authenticate, the extension will pop up the VS credential dialog (NuGet.VisualStudio.VisualStudioCredentialProvider.PromptForCredentials). As the authentication service is forms based I entered just my user name and password but it was rejected.
On closer inspection that method returns a NetworkCredential with the entered credentials, but it also sets the Domain property to some value ("INTRANET" in my case) and makes the credential useless. After some poking I discovered that if I enter
my username as <server>\<username>, where <server> is the same server specified in the feed, then the Domain property will remain empty and the request will authenticate correctly.
In this case I don't know if Nuget can do anything to avoid this hidden property setting. I guess, for this use case, the Domain property should be empty by default (to behave the same as in NuGet.config).