0

我正在尝试配置我的 Apache 反向代理以匹配 git 客户端使用 HTTP 后端访问的 URI，以进行身份​​验证¹。为此，我想在代理上匹配 URI 上的 HTTP 请求并以不同方式对待它们。后面部分没有问题，但我很难找到一个好的 URI 模式/列表来匹配这些请求。

到目前为止我发现的是：

  • 试验了记录服务器端（访问日志）和客户端（GIT_CURL_VERBOSE=1）。目前观察到：
    • GETs on <base-url>/info/refs?service=git-upload-pack
      （ls-remote，或初步获取/克隆）
    • GETs on <base-url>/info/refs?service=git-receive-pack
      （git push 的初步）
    • 发布到<base-url>/git-upload-pack
      （git fetch）
    • 发布到<base-url>/git-receive-pack
      (git push)

  • Git book on transfer protocols 中的文档，但这在设计上似乎不完整：

    本节包含传输协议的非常基本的概述。该协议包括许多其他功能，例如 multi_ack 或边带功能，但涵盖它们超出了本书的范围。

  • git-http-backend 手册页中建议的 Apache 配置。

    • 它假设您在单独的前缀上​​提供 git 存储库，但情况并非总是如此（请参阅我的脚注）。
    • 像这样的部分RewriteCond %{QUERY_STRING} service=git-receive-pack假设没有其他东西在同一个 VirtualHost 上提供服务，因为它会破坏非 Git 资源，除非我添加不带查询字符串的 URI 匹配的附加要求 ~ /info/refs$。
    • 虽然它可能仍然是最新的，但它似乎有点过时了，因为它仍然显示 Apache 2.2 的授权配置示例。这让我想知道这是否得到了适当的更新并适合可靠的来源。

简单列出上述模式也让我担心的是：

  • 也许某些客户端的操作方式不同，例如“哑协议”或“智能协议 v2”？
  • Git 协议 2 可能会改变事情，或者不会？
  • 我真的找不到协议的HTTP 部分的规范。我可以在协议的 Git 级别找到很多东西，但从反向代理的角度来看，这不是我感兴趣的。
  • 结果，我可能会破坏用户的东西，由于代理上的模糊 URI 匹配，这很难调试......

因此，理想情况下，我想指出一些文档/代码，它显示了 git http 客户端可以操作的 URI 的完整概述。它可能是一个简单的正则表达式——这就是我最终要寻找的——只要它是权威的。

¹我正在尝试使用 Apache 作为身份验证反向代理执行 SSO 登录，通过 HTTPS 与常规网页对 Git 进行不同类型的身份验证。该应用程序 Gerrit Code Review 通过具有 SSO 身份验证并启用的公共 URL 前缀为页面和Git存储库提供服务auth.trustContainerAuth，因此我无法真正匹配例如.^/git/.*git-http-backend

4

1 回答 1

1

智能和哑 HTTP 的路径列表在源代码中。请注意，它不包括查询参数或内容类型。

请注意，正在向 Git 添加 SHA-256 支持，因此现在接受 40 个字符的十六进制字符串的任何内容将来也将处理 64 个字符的十六进制字符串。

于 2019-02-16T21:20:35.130 回答