libgit2sharp usernamepasswordcredentials 似乎忽略了用户名？

Question

我们正在使用 GIT 进行部署，而且一切运行良好。目前我正在编写允许客户端切换到另一个部署存储库的功能 - 毕竟我们可能会在某个时候决定从不同的位置开始部署，对吧？

我们在 Azure 中创建存储库，并在创建存储库后使用按钮生成 GIT 凭据：

所以我向用户展示了一个表单，他们可以在其中输入新的 URL、用户名和密码，然后我去检查....（vb.net 代码）

    Dim oCH As LibGit2Sharp.Handlers.CredentialsHandler = Nothing
    Dim oItems As IEnumerable(Of LibGit2Sharp.Reference) = Nothing
    Dim oCred As LibGit2Sharp.UsernamePasswordCredentials = Nothing

    Try
        oCred = New LibGit2Sharp.UsernamePasswordCredentials
        oCred.Username = tbBuildsCredential.Password
        oCred.Password = tbBuildsPassword.Password
        oCH = New LibGit2Sharp.Handlers.CredentialsHandler(Function(_url, _user, _cred) oCred)
        oItems = LibGit2Sharp.Repository.ListRemoteReferences(url:=tbBuildsRepository.Text,
                                                              credentialsProvider:=oCH)
        If oItems Is Nothing Then
            Return False
        End If
    Catch ex As Exception

（我将省略最后的错误处理和清理代码，因为它不相关）

好的 - 所以我正在对此进行测试，并在 azure devops 中输入一个有效的存储库 URL：

https://<ourcompanynamehere>@dev.azure.com/<ourcompanynamehere>/<projectnamehere>/_git/<repohere>

我使用了一个有效的用户名和密码，一切都很好，花花公子，它返回一个 oItems 对象，它的 .Count > 0 ...快乐的日子。所以我尝试使用一些无效值来查看会发生什么... 无效的 URL 返回 此遥控器从未连接过 - 快乐的日子！所以我尝试使用正确的 URL 但无效的用户名....哇等等....它仍然返回一个有效的 oItems 对象？？？当我破坏密码时，它再次返回 此遥控器从未连接过，但似乎用户名被完全忽略了。

这是 dev.azure.com 的 GIT 方式中的错误吗？这是我需要担心的事情吗？如果无论如何都要忽略“用户名”，为什么还要有一个“用户名”？

Answer 1

这是 dev.azure.com 的 GIT 方式中的错误吗？如果“用户名”无论如何都被忽略了，为什么还要有一个“用户名”？

不，这是预期的操作，因为您使用Git Credential Manager (GCM) 生成密码。

实际上，它不是官方密码。在您单击按钮Generate Git Credentials 后，它生成的是一个个人访问令牌，其范围仅限于Repos(Read&Write)。

此时，转到Security(https://dev.azure.com/{orgname}/_usersSettings/tokens) 页面，您会看到添加了一个令牌，Token name 类似于git: https://dev.azure.com/{orgname} on {machine platform}.

对于个人访问令牌，我相信您已经知道 PAT 令牌在生成时与单个用户帐户相关联。换言之，使用 PAT 作为授权方式时，您不需要额外输入用户名。这就是用户名无论如何都会被忽略的原因。

您也可以查看此文档以获取How the Git Credential Managers works

---

这是我需要担心的事情吗？

只要把它当作密码来保密就不会造成太大的问题。

大多数时候，您不必担心。因为这个令牌很快就会过期，不会超过 1 天。

另外，正如我上面提到的，这个令牌的范围仅限于具有Read&Write 权限的Repos。即使有人不小心拿到了这个token，也不能在Repos之外进行操作。