如何使用个人访问令牌在URL中访问GitHub

Question

我维护一个私有代码库，但想要将其中一个文件公开。

GitHub文档指出以下CURL命令可以检索文件：

curl -u username:token https://api.github.com/user

但我想通过URL提供访问。例如：

https://username:[e-mail]/me/repo/master/README.md

这总是返回404。我有什么遗漏吗？

- Kye

Answer 1

从 "如何使用命令行下载私有github仓库中的单个原始文件?"，您需要使用不带用户名的PAT（个人访问令牌）：

curl -s https://$[e-mail]/....

但我不建议以任何方式公开该令牌：这将允许访问该文件和存储库的其余部分。

将该文件放在单独的位置（无论是单独的公共存储库还是任何其他在线文本存储服务）会更安全。

- VonC

---

奇怪的是，这在浏览器中不起作用。 "-s" 是否将令牌添加到 HTTP 标头中？ - Kye

你是正确的。我计划将令牌隐藏在 API 网关后面。 - Kye

@Kye -s 是用于静默模式的。使用“-kLv”进行测试，以检查错误消息是什么。 - VonC

基本身份验证功能已被几乎所有浏览器弃用，因为存在安全问题。@Kye - J.Z

@J.Z 确实。我刚在《安全现场》第763期中听到了同样的事情，由Steve Gibson介绍。节目笔记：https://www.grc.com/sn/sn-763-notes.pdf，第6页。 - VonC

Answer 2

对于那些想知道为什么要使用404而不是401的人，这基本上是GitHub采取的一项安全措施，以输出404而不是401: https://docs.github.com/en/github-ae@latest/rest/overview/other-authentication-methods#basic-authentication

对于那些想知道为什么在浏览器中我们得到了404错误，而cURL却给出了成功响应的人，你可能会认为在URL中提供用户名和密码（如https://username:[e-mail]）会在初始请求中传递凭据。但事实并非如此——浏览器会介入并查看您请求的页面是否返回WWW-Authenticate响应头，只有在这种情况下它才会发送您的凭据。在您的GitHub URL的情况下，该资源没有返回WWW-Authenticate。如果它确实返回了WWW-Authenticate，那么您显然就不会遇到这个问题。

然后还有cURL。cURL默认假定基本身份验证，并自动将授权标头设置为您的用户名和密码（从url中，如我的先前示例，或通过CLI选项设置，如您的示例），并且无论服务器是否返回WWW-Authenticate响应标头，它都会发送它。

不幸的是，我们没有办法强制浏览器在初始请求时发送它。至于为什么GitHub不发送WWW-Authenticate响应标头，可能是因为他们不想推广最不安全的身份验证方式 - 毕竟，他们不再允许以这种方式发送帐户密码。但是，他们确实意识到了它的易用性，并通过允许用户使用oAuth访问令牌、GitHub应用程序安装访问令牌或个人访问令牌来代替它，从而减轻了一些较弱的点。所以，实际上，是浏览器遵循标准，GitHub允许一种基本身份验证形式进行一些更改，而cURL立即将我们的凭据传递到授权标头中。我相信以下是在您的请求后面发生的事情：

cURL发送请求以及授权标头→GitHub：“好吧，我没问，但是是的，您的凭据检查通过”→GitHub：已授权并重定向到资源

浏览器发送请求并等待 WWW-Authenticate 响应，然后再提交凭据 → GitHub: "嗯，您没有访问此资源的权限，但我不能告诉您它是否实际存在") → GitHub: 返回 404（而不是带有 WWW-Authenticate 标头的 401），从而阻止浏览器接收 WWW-Authenticate 标头响应，并发送带有手头凭据的授权标头。

- Kerry Johnson