"Custom API Key" Configuration does not work as expected

[Joachim Roppert]

In the ProGet Documentation, 3 different API Key configurations are described. I'm using "Custom API Key" Configuration. That means

• I've configured an API Key on the Feed property page (Minor issue: Would be nice to see it directly in the properties table and not only when editing properties)
• I'm using a private feed and have provided credentials in the nuget.config (this generally works)
• The user has the Feeds_AddPackage privilege assigned

I' mushing using the following command:
nuget.exe Pack.1.0.0.nupkg xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -source https://myserver/nuget/myfeed

What i get is the following:

Pushing Pack.1.0.0 to 'https://myserver/nuget/myfeed'...
Using credentials from config. UserName: xxxxxxxxxx
Failed to process request. 'There was an error processing the request: You are not authorized to add 
a package to this feed. By default, ProGet is not configured to allow unauthenticated users to publish
packages to a feed. You will need to either authenticate (by using "name:pass" as your API Key) or give
the Anonymous User the Feeds_AddPackage privilege.'.
The remote server returned an error: (403) Forbidden..

Am I doing something wrong? As of the documentation, my understanding is that it should be possible to specify credentials for authentication in the nuget.config and providing a valid API key in the nuget push command. I don't want to provide credentials in the nuget push command line since it's part of the build process and readable by everyone while the nuget.config is protected on the build server.

Product: ProGet
Version: 3.4.7

[Dean]

This certainly used to work. It looks like nothing has changed on our end. I did some quick testing here with the latest NuGet client and can't seem to get it to send credentials with a push no matter what I do. Based on the error message you've pasted above, it looks like you're having the same issue (that message is only displayed if no auth credentials are present). You can double-check that this is happening in Fiddler, of course, but it looks like this is due to a change in behavior of NuGet.exe.