Mercurial управление пользователями и безопасность - PullRequest
3 голосов
/ 20 октября 2011

Я только что установил Mercurial 1.9.3 на свой сервер Centos 5.5 x64.Я публикую свои репозитории, используя hgweb.wsgi и mod_wsgi.

Этот сервер предназначен только для использования нашей внутренней кодовой базой и командой разработчиков, поэтому я также защитил свой сервер, используя .htaccess и базовый HTTPаутентификация.Это все хорошо, и я могу клонировать репозитории в локальные и перенести изменения обратно в центральный репозиторий.

Есть одна вещь, которую я не правильно понимаю, а именно, как контролировать и управлять пользователями.

Например, у меня есть два пользователя на моем сервере центрального хранилища .htpassword file: bob и kevin.

На каждой из локальных машин bob и kevin ониимеют собственные файлы Mercurial .hgrc с настроенными настройками username.

Однако эти .hgrc пользователи, похоже, не имеют никакого отношения к пользователю, указанному в файле .htpassword удаленного сервера.

Это означает, что я могу получить толчки к центральному хранилищу, исходящие от «Микки Мауса» и «Дональда Дака», что бесполезно.

Как принудительно установить сквозное сопоставлениелокальное .hgrc имя пользователя для пользователя .htpassword для поддержки, т.е. убедитесь, что пользователь, указанный в .hgrc, совпадает с .htpassword пользователем?

Ответы [ 2 ]

6 голосов
/ 20 октября 2011

Это не совсем ответ, но стоит сказать: Сначала все об этом беспокоятся, но на практике это не проблема .

В то время, когда пользователь совершает коммит с DVCS, будь то Mercurial, git или другой, он не обязательно подключен к какой-либо системе аутентификации / авторизации, которую вы контролируете, поэтому его коммиты обязательно фиксируются (локально) с любым авторством Информация, которую они хотят отстаивать. Позже вы можете отклонить эти наборы изменений на push на репо / сервере, которым вы управляете, но это будет большой проблемой для вас и для них. Это не просто вопрос повторного ввода их имени / пароля, они должны изменить историю этого набора изменений и всех последующих наборов изменений, чтобы изменить информацию об авторстве.

Список абсолютно неудовлетворительных решений на это:

  • отклонять толчки, когда авторство набора изменений не соответствует аутентифицированным пользователям, использующим хук (на практике это отстой, потому что разработчики отталкиваются друг от друга и постоянно выдвигают изменения друг друга)
  • Заставьте разработчиков подписывать свои наборы изменений с помощью расширения gpg или hgsigs (огромные хлопоты, и они забудут)
  • ведет pushlog на сервере, где записывается прошедший проверку подлинности пользователь, который выдвинул каждую ревизию отдельно от ее авторства (Mozilla делает это, и это меньше хлопот, чем другим, но все же вряд ли когда-либо с ним будут обращаться).

Если вы явно не можете рисковать фиктивными ревизиями, входящими в конкретное репо, тогда используйте человеческий фильтр, когда люди подталкивают к общему репо A, и только рецензент / buildmanager / вы можете толкать из репо A в репо B, где репо B является официальным сборки приходят из. Сам Mercurial использует эту систему.

В конце концов, мой совет не беспокоиться об этом. Разработчики, которых стоит нанимать, гордятся тем, что ставят свое имя в свои коммиты, а если у вас нет разработчиков, достойных найма, вы уже обречены на провал.

0 голосов
/ 20 октября 2011

Как принудительно установить сквозное сопоставление локального имени пользователя .hgrc с пользователем .htpassword для поддержки

Нет способов сделать это. Но (вместо этого) расширение ACL + ssh (hg-ssh или mercurial-server) дает более предсказуемые результаты

PS

[ui] username =

применимо и имеет смысл только в контексте изменений-комментариев, как примечание, не более

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...