【问题标题】:Configuring NuGet server to use Authentication配置 NuGet 服务器以使用身份验证
【发布时间】:2013-07-29 11:36:19
【问题描述】:

NuGet 1.5 状态的release notes

NuGet now supports connecting to private repositories that require basic 
or NTLM authentication.

但是,其中包含的链接只是指向hosting your own nuget feeds 页面,没有进一步提及如何设置身份验证。

我想设置一个可以通过 https 从 Internet 访问的 NuGet 服务器,但只允许成功通过身份验证的人查看或下载服务器上的包。

我确实按照documentation 中的创建远程源 部分所述创建了一个没有身份验证的应用程序,并且它在Intranet 上运行良好。我需要做什么才能在这个 repo 上启用身份验证?

另外一个要求是解决方案不应花费数百美元(前两个答案推广的产品可能会解决问题但成本很高)。

【问题讨论】:

    标签: authentication iis nuget ntlm nuget-server


    【解决方案1】:

    如果您想要真正安全的提要并将它们公开到互联网,您可能需要查看MyGet.org,您可以在其中创建需要基本身份验证的私有提要,默认情况下使用 SSL/HTTPS。

    使用您的首选身份提供商(Live Id、Facebook、Google、Stackoverflow、GitHub、OAuth 等),甚至您自己的公司,只需点击几下注册,即可邀请您想要的人加入您的提要并分配他们的权限ADFS(企业计划)。

    更多信息:https://www.myget.org/plans 有关在 Visual Studio 或构建服务器上设置身份验证的帮助,请查看我们的文档https://docs.myget.org 和我们的blog。如果您需要进一步的帮助,我们很乐意通过Twitter、通过我们的联系表或通过带有 MyGet 标记的 StackOverflow 问题提供帮助。

    【讨论】:

    • 是的,我看到了 MyGet,但在某些服务器上托管我们的库不是一个选择。
    【解决方案2】:

    我实际选择的解决方案是使用 TeamCity 作为 NuGet 服务器;虽然设置起来有点麻烦,因为它缺少 nuget 推送功能,但它现在可以很好地工作,并且仅向经过身份验证的用户提供 NuGet 包而无需额外费用。

    【讨论】:

      【解决方案3】:

      这可以通过在网站上启用 Windows 身份验证并通过 Sources 命令行选项在构建服务器上添加凭据来完成,默认情况下,凭据使用仅限于当前用户的 DPAPI 密钥存储在当前机器(因此,对于构建服务器,您需要在使用服务帐户登录时添加凭据。)

      对于开发人员工作站,您只需在 NuGet 包管理器中添加提要,然后在刷新提要时输入/存储凭据(应该会提示您。)

      第 1 步 - 要求在 NuGet 服务器上进行身份验证(IIS 配置)

      您需要确保为 IIS 安装了您希望使用的身份验证模块,对于 NTLM 身份验证,您将需要 Windows 身份验证模块。安装后,您可以打开 IIS 管理器并深入了解您的网站,打开身份验证设置并启用 Windows 身份验证,请务必禁用任何您不想支持的身份验证模块(例如匿名、基本等)

      要确保使用用户凭据,请右键单击站点并选择“高级设置”,然后单击“物理路径凭据”按钮。在对话框中确保选择了“应用程序用户(直通身份验证)”。

      有关 Windows 身份验证的标准 IIS 配置的更多详细信息,请参阅 on TechNet,包括从命令行配置和启用协商(如果这是您的目标)。

      第 2 步 - 将源添加到 NuGet 配置(构建服务器、发布者)

      nuget.exe sources add -Name "Fabrikam Feed" -Source "https://nuget.fabrikam.com:443/nuget/"
      nuget.exe sources add -Name "Fabirkam Publish" -Source "https://nuget.fabirkam.com:443/"
      

      这里我们添加了两个条目,一个将用作正常的、经过身份验证的 Feed URL(用于从服务器获取包。)第二个将用于发布到服务器(添加或更新 nupkg 文件。)

      第 3 步 - 更新添加源的凭据(构建服务器、发布者)

      nuget.exe sources update -Name "Fabrikam Feed" -Source "https://nuget.fabrikam.com:443/nuget/" -UserName "Developer" -Password "g0d"
      nuget.exe sources update -Name "Fabrikam Publish" -Source "https://nuget.fabrikam.com:443/" -UserName "Developer" -Password "g0d"
      

      我们在此处为配置添加了凭据,如果您查看 %APPDATA%\NuGet\NuGet.config,您应该会看到您添加的提要以及加密的凭据。

      如果您无法以服务器身份登录,则可以使用 StorePasswordInClearText 选项以明文形式存储凭据,但不建议在共享环境中这样做。

      第 4 步 -(可选)在 Visual Studio(开发人员)中禁用发布 URL

      打开 Visual Studio 并导航到 NuGet 包管理器设置对话框,取消选中“Fabrikam Publish”提要。这不会影响您发布的能力,但是,如果您不禁用此提要,您将在尝试刷新“所有”源的包时收到错误消息(因为它是发布 URL,而不是提要 URL。)

      第 5 步 -(可选)在 Visual Studio 中存储 Windows 凭据(开发人员)

      打开 Visual Studio 并导航到 NuGet 包管理器,单击“Fabrikam Feed”。应提示您输入凭据。您可以在此处输入凭据并勾选保存/记住选项。这可确保尝试在 Visual Studio 中刷新提要不会不断要求提供凭据。在最新版本的 NuGet 包管理器中,提要是使用标准 HTTP 请求获取的,并且不会使用您存储到 nuget.config 的凭据。

      注意事项:

      1. 您不需要第三方解决方案来托管私密、安全的 Feed。 NuGet 服务器免费提供,并且 IIS 和 NuGet 工具都支持 NTLM/AD/Windows 安全性。

      2. 不需要发布到提要的开发人员不需要在他们的配置中存储凭据。他们也不需要配置“发布”提要。这仅对构建服务器或其他发布者是必需的(参考:步骤 2 和 3。)

      3. 所有将使用软件包提要的开发人员都会对第 5 步感兴趣,这应该是大多数开发人员所需要的全部内容。他们可以简单地从 Visual Studio 中添加提要,然后在出现提示时输入他们的凭据。

      4. 如果凭据发生更改,您可以导航到开始 -> 管理 Windows 凭据并删除“VSCredentials_nuget.fabrikam.com”。

      5. 第 2 步可以在 Visual Studio 中执行,但为了清楚起见,我在这里给出了命令行。但是,第 3 步必须通过命令行(或使用 NuGet API)执行。

      6. 在 NuGet 的未来版本中,有传言称凭据信息可以存储在解决方案或项目级别(细节尚不清楚),这可能只对他们无法访问的多租户构建环境中的人感兴趣构建服务器。

      希望这对其他人有帮助!

      【讨论】:

      • 这个答案实际上并没有回答这个问题。它只涉及在客户端上设置 nuget,而不是在服务器上。它假定问题中提出的实际问题(经过身份验证的服务器)已经解决。
      • 那是因为原来的 SO 标题是“配置 nuget 以使用身份验证”,这是一个常见问题,但是,我已经通过 IIS 身份验证配置的附加步骤更新了答案,包括指向technet 参考文章,详细解释了 auth 配置。此答案应作为 NuGet 服务器、构建服务器/发布者和开发人员的全面解决方案。
      • 如果我按照你的建议在 IIS 上启用 NTLM,只有拥有有效 AD 凭据的人才能从该服务器下载包?
      • @Shaun Wilson,很棒的帖子!非常感谢。虽然它不是 100% 准确,因为第 2 步和第 3 步方法在最新版本的 Nuget 中也不起作用,因为也存在错误。见nuget.codeplex.com/workitem/4096?FocusElement=CommentTextBox
      • aye .. 我实际上创建了那个错误报告,因此我们在构建服务器上保留了 nuget 2.7.x 的副本,以执行“nuget push”,但开发人员工作站当然有从开发人员(非发布者)的角度来看,最新的工具(2.8.x)和上述大部分内容仍然适用。希望他们能在某个时候修复这个错误,我们可以重新使用最新的 nuget.exe 来推送包。
      猜你喜欢
      • 2019-11-17
      • 1970-01-01
      • 2015-09-06
      • 1970-01-01
      • 2021-02-04
      • 1970-01-01
      • 2021-04-30
      • 1970-01-01
      • 2017-02-03
      相关资源
      最近更新 更多