我在VM中设置了TFS 2017,创建了一个项目并添加了包源扩展。然后我创建了一个具有完全访问权限的订阅源和个人访问令牌。
我的问题是我无法使用nuget.exe
3.5.0
和个人访问令牌从命令行将包推送到feed。我正在使用here上的说明并在供稿页面上(下面的第二个命令)
我的命令:
nuget.exe sources Add -Name MyFeed -Source "http://server2016:8080/tfs/DefaultCollection/_packaging/MyFeed/nuget/v3/index.json" -Username administrator -Password x7m5hochjcf4vabp3zqeekrzi7mtbyk6at5tujdt2ny5fgienlgq
nuget.exe push -Source "MyFeed" -ApiKey VSTS C:\temp\octopack.3.4.6.nupkg
nuget.exe list -Source MyFeed
我得到的push
和list
的输出:
Using credentials from config. UserName: administrator
Please provide credentials for: http://server2016:8080/tfs/DefaultCollection/_packaging/MyFeed/nuget/v3/index.json
UserName:
我尝试再次输入用户名和PAT,但它只是再次提示我。
如果我使用我的Windows凭据(与PAT相同的帐户),它可以正常工作。我和Fiddler一起检查过,auth挑战已经发送并回复了。服务器返回401。
知道为什么TFS不接受PAT吗?
从nuget 5.0开始,您可以设置“ValidAuthenticationTypes”。见nuget sources -?
-ValidAuthenticationTypes Comma-separated list of valid authentication types for this source. By default,
all authentication types are valid. Example: basic,negotiate
这将控制nuget.config中的新键
<add key="ValidAuthenticationTypes" value="basic" />
这可以防止nuget针对您的本地TFS / AzureDevOps服务器尝试协商/ NTLM / Kerberos身份验证。
这里的问题通常是谈判阻碍。 Nuget(以及构建在底层库上的工具,如'msbuild / restore'或'dotnet')擅长在登录时使auth变得简单,AD可以为您协商NTLM / Kerberos。不幸的是,在配置基本信用时,它可以尝试在协商期间将其传递掉,但这会失败。值得注意的是,这只是本地服务器实例的问题,而不是azure.dev.com/visualstudio.com云托管实例,因为Negotiate不会在云方案中触发。
这部分是在credentialProvider插件流下解决的,它可以返回其信任的auth类型,如果设置了特定的环境变量,nuget将禁用UseDefaultCredentials并跳过协商(这在Azure Pipelines中用于TFS / AzureDevops服务器的nuget auth )。
它使用https://github.com/NuGet/NuGet.Client/pull/2297在nuget 5.0中进行了最终修复,当手动指定基本身份验证的PAT /密码时,它甚至可以在配置文件中设置auth类型。截至目前,nuget docs仍然是pending。
如果使用Active Directory,则VSTS代理服务不应与NETWORK_SERVICE帐户一起使用。
首先,您需要为服务设置Active Directory帐户。之后,您必须从TFS上的Feed Permissions选项卡授予此用户权限。
也许你需要在-StorePasswordInClearText
命令中添加nuget.exe sources Add
选项。