Я пытаюсь настроить свой обратный прокси-сервер Apache для соответствия URI, к которым обращаются клиенты git, использующие HTTP-бэкенд, для целей аутентификации¹.Для этого я хотел бы сопоставить HTTP-запросы на URI на прокси и обрабатывать их по-разному.В последней части проблем нет, но у меня проблемы с поиском подходящего шаблона / списка URI, соответствующих этим запросам.
На данный момент я нашел следующее:
- Экспериментировал с ведением журналасторона сервера (журналы доступа) и сторона клиента (
GIT_CURL_VERBOSE=1).Наблюдаемые до сих пор: - GETs на
<base-url>/info/refs?service=git-upload-pack(ls-remote или предварительный выбор / клон) - GETs на
<base-url>/info/refs?service=git-receive-pack(предварительно для git push) - POST к
<base-url>/git-upload-pack(git fetch) - ПОЧТЫ к
<base-url>/git-receive-pack(git push)
Документация в книге Git по протоколам передачи , но она кажется неполной в дизайне:
Этот раздел содержит очень простой обзор протоколов передачи.Протокол включает в себя множество других функций, таких как возможности multi_ack или боковой полосы, но их охват выходит за рамки этой книги.
Предлагаемая конфигурация Apache в man-страница git-http-backend .
- Предполагается, что вы обслуживаете git-репозитории с отдельным префиксом, что не всегда так (см. мою сноску).
- Часть, подобная
RewriteCond %{QUERY_STRING} service=git-receive-pack, делает предположение, что больше ничего не обслуживает тот же VirtualHost, потому что это нарушит не-Git ресурсы с этим, если я не добавлю дополнительное требование, чтобы URI без строки запроса соответствовал ~ /info/refs$. - Несмотря на то, что он все еще актуален, он выглядит несколько устаревшим, поскольку он все еще показывает примеры конфигурации Apache 2.2 с авторизацией.Это заставляет меня задуматься, обновлено ли оно соответствующим образом и подходит ли оно для надежного источника.
Меня также беспокоит простой список перечисленных выше шаблонов:
- Возможно, некоторые клиенты работают по-другому, например, «тупой протокол» или «умный протокол v2»?
- Протокол Git 2 может что-то изменить, или нет?
- Не могу найтиспецификация частей HTTP протокола.Я могу найти многое на Git-уровне протокола, но это не то, что меня интересует с точки зрения обратного прокси-сервера.
- В результате я могу разбить материал для пользователей, что трудноотладка из-за неясного соответствия URI на прокси ...
Итак, в идеале, я бы хотел указать на некоторую часть документации / кода, которая показывает полный обзор того, какие URI обращаются к клиентам http может работать.Это может быть простое регулярное выражение - в конце концов, это то, что я ищу в конце - до тех пор, пока оно является авторским.
trying Я пытаюсь выполнить SSO-вход с использованием Apacheкак аутентификация обратного прокси-сервера, с другим типом аутентификации для Git через HTTPS по сравнению с обычными веб-страницами.Приложение Gerrit Code Review обслуживает обе страницы и Git-репозитории по общему URL-префиксу с SSO-аутентификацией и включенной auth.trustContainerAuth, поэтому я не могу точно подобрать, например, ^/git/.*, как указано на man-странице git-http-backend.