logo标签列表

使用OAuth访问令牌进行GitHub克隆

gitgithuboauth
250

在一个脚本中，我正在尝试使用OAuth令牌克隆GitHub存储库。

根据这个教程：

https://github.com/blog/1270-easier-builds-and-deployments-using-git-over-https-and-oauth

我应该能够构建如下命令：

git clone https://<token>@github.com/owner/repo.git

如果我手动使用正确的访问令牌尝试这个操作，它仍然要求我输入密码。

如果我在命令行上尝试，我只会得到一个“找不到存储库”的错误。

这篇文章是2012年的，我找不到任何关于这方面的API文档。所以我想知道这是否仍然有效。

1
“如果我手动尝试”和“如果我在命令行上尝试”有什么区别？ - Sebastian Mach
请修正URI-token语法，参见https://dev59.com/k18e5IYBdhLWcg3wwMhW#29570677。 - Peter Krauss
@PeterKrauss 引用一个无关的主题似乎有点不必要，特别是如果它是一个“关闭”的话题。 - deiga
请查看底部的答案！ - Robert Moskal
13个回答
2
在 .net core 中，当处理 Azure DevOps Repo 时，您可以按照以下方式进行操作：

最初的回答

 public void CloneRepository()
        {
            var _gitURL = "URLofGitRemoteRepository";
            var _userName = "PersonalAccessToken";
            var _pswd = ""; //Keep it blank

            var co = new CloneOptions();
            co.CredentialsProvider = (_url, _user, _cred) => new UsernamePasswordCredentials { Username = _userName, Password = _pswd };

            Repository.Clone(_gitURL, filePath, co);
        }
1
您需要在令牌前面填写用户名。GitHub接受任何用户名。oauth2适用于GitHub和GitLab。
git clone https://oauth2:token@github.com/owner/repo.git

然而，在https Git URL中包含凭据被视为不良做法，因为它会导致配置文件和命令历史中的凭据意外暴露。

此外，当令牌过期时，它将无法使用。对于诸如GitLab和BitBucket之类的主机，令牌的有效期可能只有两个小时。

更安全、更可靠的方法是使用凭证生成助手，例如Git Credential Manager（已包含在Git for Windows中）或git-credential-oauth（已包含在多个Linux发行版中）。

第一次进行身份验证时，助手会打开一个浏览器窗口来访问主机。随后的身份验证将不需要交互。

这些助手会根据需要刷新过期的OAuth令牌。

0
应该在Git 2.41（2023年第二季度）得到更好的支持，凭据子系统学会了帮助OAuth框架。
请参阅commit a5c7656（2023年4月21日），作者为M Hickford (hickford)。
（由Junio C Hamano -- gitster --合并于commit 2ca91d1，2023年5月10日） 凭证：新属性oauth_refresh_token

签署者：M Hickford

Git authentication with OAuth access token is supported by every popular Git host including GitHub, GitLab and BitBucket.
Credential helpers Git Credential Manager (GCM) and git-credential-oauth generate OAuth credentials.
Following RFC 6749, the application prints a link for the user to authorize access in browser.
A loopback redirect communicates the response including access token to the application.

For security, RFC 6749 recommends that OAuth response also includes expiry date and refresh token.
After expiry, applications can use the refresh token to generate a new access token without user reauthorization in browser.
GitLab and BitBucket set the expiry at two hours.
(GitHub doesn't populate expiry or refresh token.)

However the Git credential protocol has no attribute to store the OAuth refresh token (unrecognised attributes are silently discarded).
This means that the user has to regularly reauthorize the helper in browser.
On a browserless system, this is particularly intrusive, requiring a second device.

Introduce a new attribute oauth_refresh_token.
This is especially useful when a storage helper and a read-only OAuth helper are configured together.
Recall that credential fill calls each helper until it has a non-expired password.

    helper = storage  # eg. cache or osxkeychain
    helper = oauth

The OAuth helper can use the stored refresh token forwarded by credential fill to generate a fresh access token without opening the browser.
See https://github.com/hickford/git-credential-oauth/pull/3/files for an implementation tested with this patch.

Add support for the new attribute to credential-cache.
Eventually, I hope to see support in other popular storage helpers.

Alternatives considered: ask helpers to store all unrecognised attributes.
This seems excessively complex for no obvious gain.
Helpers would also need extra information to distinguish between confidential and non-confidential attributes.

Workarounds: GCM abuses the helper get/store/erase contract to store the refresh token during credential get as the password for a fictitious host (I wrote this hack).
This workaround is only feasible for a monolithic helper with its own storage.

git凭据现在在其man页面中包含：

oauth_refresh_token

一个OAuth刷新令牌可能伴随着作为OAuth访问令牌的密码。辅助工具必须像密码属性一样将此属性视为机密信息。Git本身对此属性没有特殊行为。

通过Git 2.43（2023年第四季度），重新思考了除密码以外的身份验证相关数据（例如oath令牌和密码过期数据）在libsecret密钥环中的存储方式。

请参见commit 0ce02e2（2023年6月16日）由M Hickford（hickford）提交。
（由Junio C Hamano -- gitster --合并于commit e839608，2023年8月28日）

credential/libsecret：存储新属性 已签署：M Hickford

d208bfd (credential: new attribute password_expiry_utc, 2023-02-18, Git v2.40.0-rc1 -- merge) and a5c7656 (credential: new attribute oauth_refresh_token, 2023-04-21, Git v2.41.0-rc0 -- merge listed in batch #18) introduced new credential attributes.

libsecret assumes attribute values are non-confidential and unchanging, so we encode the new attributes in the secret, separated by newline:

hunter2
password_expiry_utc=1684189401
oauth_refresh_token=xyzzy

This is extensible and backwards compatible.
The credential protocol already assumes that attribute values do not contain newlines.

Alternatives considered: store password_expiry_utc in a libsecret attribute.
This has the problem that libsecret creates new items rather than overwrites when attribute values change.

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接