Home: dotnet restore does not prompt for user input when authenticating

Created on 2 Jun 2016  路  14Comments  路  Source: NuGet/Home

The Problem

When using a Nuget repository that requires authentication, dotnet restore fails with a 401 Unauthorized unless the password is provided in cleartext in the Nuget config file.

However, having cleartext passwords in the config file isn't great, and with the original (non-dotnet) workflow, if there were no passwords in the config file, "nuget restore" on the command line would prompt for username/password credentials. Doing a nuget restore from within VS2015 would pop up a dialog box asking for username/password credentials as well.

Running "dotnet restore" does not prompt for any credentials at all, but just instantly fails after getting the 401 Unauthorized. This is also the case when restoring within a VS2015 ".NET Core" project - no credential dialog appears.

Expected behavior

If the Nuget repository requires authentication and there are no credentials in the config file, "dotnet restore" should prompt for credentials when run from the command line or from within VS2015, the same way that "nuget restore" does.

Actual behavior

"dotnet restore" does not prompt for credentials and just fails with 401 Unauthorized.

Environment data

dotnet --info output:
.NET Command Line Tools (1.0.0-preview1-002702)

Product Information:
Version: 1.0.0-preview1-002702
Commit Sha: 6cde212

Runtime Environment:
OS Name: Windows
OS Version: 6.1.7601
OS Platform: Windows
RID: win7-x64

I'm using NuGet version 3.4.3.855.

Authentication Xplat 3 WaitingForCustomer

Most helpful comment

Any news here? This is a terrible bug... so if the nuget gallery requires authentication... nothing that we can do?!

All 14 comments

Reported in https://github.com/dotnet/cli/issues/3097.

Currently NuGet XPlat doesn't support interactive scenario. Need to verify what was the issue blocking it.

Any updates on this? Thanks!

//cc @rrelyea @yishaigalatzer @emgarten for triage

Apologies for the nudge but any update on this? Thanks!

@lszomoru is there a specific scenario you have where entering the credentials in manually is needed instead of using a config file?

At the moment I am working on a .NET Core project in which I am trying to use multiple private packages that are being stored in VSTS. If my understanding is correct, the only way to get "dotnet restore" to work is to create a personal access token and store this personal access token as clear text in the nuget.config file. I think that the end goal should be to get "dotnet restore" to work the same way as "nuget restore" which just works with packages stored in private feeds. thanks!

The issue is that your authentication failed. If you do the following:

nuget.exe sources Add -Name "SomeFeed" -Source "your nuget feed" -Username someuser -password somepassword -StorePasswordInClearText

Then it will work. Perhaps better error messaging is needed, and should allow us to popup authentication.

What should be done to help developers, in the meantime. Add proper logging messages for this:

Cannot authenticate to 'SomeFeed', please run this command to re-authenticate:

nuget.exe sources Add -Name "SomeFeed"
nuget.exe sources Add -Name "SomeFeed" -Source "your nuget feed" -Username someuser -password somepassword -StorePasswordInClearText

The problem is that also that .NET SDK doesn't contain nuget.exe. So after I've installed the SDK I can't install any package from my internal feed.

Any news here? This is a terrible bug... so if the nuget gallery requires authentication... nothing that we can do?!

Related https://github.com/NuGet/Home/issues/6486. We are looking into this issue and early discussion in this regard is taking place. Do monitor this thread for more info in future. (You may also want to subscribe to https://github.com/NuGet/Home/issues/6486)

Hey, reviving this issue since it seems like a pretty big blocker for CI/CD systems. Is anyone actively working on this or has it be relegated to wont fix?

The way I read this, the original ask talks about the action of prompting the user on the commandline to enter credentials to authenticate.

As @anangaur already mentioned in #6486 we will solve the problem for dotnet.exe authentication by introducing a new plugin model.
This would enable people to use feeds like VSTS (and any other feed providers, that would be able to write their own provider).

The way this will work is via device flow authentication.
dotnet.exe would print out a link and a token that a user would need to go to and complete the authentication. Once that's done, the credential provider will present NuGet with a PAT that will be used for all the other operations.

Is there a scenario in which prompting at the commandline would be favored over just adding those credentials in the config/allowing the credential plugin to do it's thing to authenticate you?

Personally I'd like us to close this issue as duplicate/won't fix to #6486

Per the above comment.

Closing this as won't fix.

Was this page helpful?
0 / 5 - 0 ratings