proxy вк - Клиент GitHub Windows за прокси-сервером





бесплатно для (9)


Я не знаю о вашем брандмауэре, но мой кампус использует прокси-сервер

вы используете какой-либо git gui? EDIT : только что заметил, что вы используете клиент github для windows

Я использую tortoisegit и его очень легко установить прокси. Просто щелкните правой кнопкой мыши в любом месте, черепаха> сеть, включите прокси-сервер и задайте адрес сервера, имя пользователя и пароль. сделанный

насколько я помню, черепаха также будет работать из коробки с github.

Я пытаюсь заставить клиент GitHub для Windows работать. Я на корпоративном компьютере Win 7 x64 за корпоративным прокси-сервером и брандмауэром. Следуя различным другим сообщениям и экспериментируя с несколькими комбинациями переменных среды и переменных конфигурации, я нашел единственный способ получить клонирование и нажимать обновления для работы, используя переменную среды HTTPS_PROXY, включая полный идентификатор пользователя и пароль для корпоративного домена.

Это неприемлемо с точки зрения безопасности. Есть ли другой способ заставить это работать?

Дополнительные замечания:

Следующие работы:

  • Добавьте переменную окружения HTTPS_PROXY со значением http://[domain]\[userid]:[password]@someproxy.mycorp.com:8080

Следующие не работали:

  • Опускание идентификатора пользователя и пароля из переменной HTTPS_PROXY
  • Использование переменной среды, называемой HTTP_PROXY (no S )
  • Добавление переменной http.proxy в глобальный файл конфигурации ( .gitconfig )
  • Добавление https.proxy в файл глобальной конфигурации

Во всех случаях клиент GitHub по-прежнему не распознает прокси: содержимое файла TheLog.txt всегда показывает следующее при запуске:

[time]|INFO|thread:4|GitHub.Helpers.StartupLogger|Proxy information: (None)
[time]|INFO|thread:4|GitHub.Helpers.StartupLogger|Couldn't fetch creds for proxy

И за ним следует вывод нескольких неудачных попыток аутентификации прокси-сервера, все из которых указывают, что «Учетные данные отсутствуют».




Добавьте эти записи в свой файл .gitconfig в свой каталог пользователя (перейдите к% USERPROFILE%):

[http]
    proxy = http://<proxy address>:<proxy port>

[https]
    proxy = https://<proxy address>:<proxy port>

И если вы не хотите хранить свой пароль в открытом тексте, я бы использовал локальный прокси-сервер, такой как CNTLM, который позволяет вам направлять весь трафик через него и хранить хэшированные пароли.

В отличие от исходного вопроса, если вам неважно, добавлен ли ваш пароль в виде простого текста :

[http]
    proxy = http://<username>:<password>@<proxy address>:<proxy port>

[https]
    proxy = https://<username>:<password>@<proxy address>:<proxy port>



Если вы используете GitHub для Windows в корпоративном секторе, есть вероятность, что вы столкнулись с большим плохим корпоративным брандмауэром / прокси. GitHub для Windows еще не имеет параметров прокси в своем графическом интерфейсе для настройки параметров.

Чтобы настроить GitHub для Windows на использование корпоративного прокси-сервера, отредактируйте файл .gitconfig, обычно находящийся в C: \ Users \ .gitconfig или C: \ Documents & Settings \ .gitconfig.

Закрыть GitHub для Windows; В .gitconfig просто добавьте

[https] proxy = proxy.yourcompany.com:port




Для нас решение включало две разные вещи. Во-первых, как описано в ответе Соггера, вам нужно добавить записи в файл .gitconfig , расположенный в %USERPROFILE% .

[http]
    proxy = http://<proxy address>:<proxy port>

[https]
    proxy = https://<proxy address>:<proxy port>

Во-вторых, (и это был недостающий элемент для нас), вам нужно настроить исключение на прокси-сервере, чтобы разрешить не аутентифицированный прокси-трафик на *.github.com

В iPrism это выглядит так:

Проблема заключается не столько в прокси-сервере, сколько в аутентификации . В обход требования проверки подлинности обеспечивается необходимая коммуникация для клонирования и работы с проектами с использованием настольного клиента GitHub.

Также обратите внимание, что этот подход не требовал хранения учетных данных прокси-сервера в файле .gitconfig .




Вот как установить прокси-сервер в github

git config --global http.proxy http://<username>:<pass>@<ip>:<port>
git config --global https.proxy http://<username>:<pass>@<ip>:<port>

Здесь, в моем колледже, у нас нет имени пользователя и пароля, поэтому, если наш колледж ip 172.16.10.10, а порт - 8080

git config --global http.proxy http://172.16.10.10:8080
git config --global https.proxy http://172.16.10.10:8080

PS -> Я бы рекомендовал использовать этот метод для установки прокси-сервера, поскольку все встанет на свои места, поскольку вы будете учиться дальше
Source




Я нашел этот блог полезным. Он описывает прокси ntlmaps . Это, вероятно, менее безопасно, но работает плавно. Я не мог работать cntlm.




Я также столкнулся с этой проблемой и попытался вникнуть в нее немного (разобрал клиент).

Часть кода, генерирующая сообщения журнала, которые мы видим, выглядит следующим образом:

private static void LogProxyServerConfiguration()
{
    WebProxy defaultProxy = WebProxy.GetDefaultProxy();
    string str = defaultProxy.Address != (Uri)null ? defaultProxy.Address.ToString() : "(None)";
    StartupLogger.log.Info((IFormatProvider)CultureInfo.InvariantCulture, "Proxy information: {0}", str);
    try
    {
        if (defaultProxy.Credentials == null)
        {
            StartupLogger.log.Info((IFormatProvider)CultureInfo.InvariantCulture, "Couldn't fetch creds for proxy", new object[0]);
        }
        else
        {
            NetworkCredential credential = defaultProxy.Credentials.GetCredential(GitHubClient.GitHubDotComUri, "Basic");
            StartupLogger.log.Info((IFormatProvider)CultureInfo.InvariantCulture, "Proxy is authenticated: {0}", credential != null && !string.IsNullOrWhiteSpace(credential.UserName));
        }
    }
    catch (Exception ex)
    {
        StartupLogger.log.InfoException("Couldn't fetch creds for proxy", ex);
    }
}

Таким образом, этот блок регистрирует только прокси-информацию, которая настроена в IE . Сообщение журнала не влияет на то, что мы установили в конфигурационных файлах или переменных окружения.




Пробовал все, что было выше - и не получилось, только то, что помогло мне, - CNTLM - http://cntlm.sourceforge.net/ .

Установите его и запустите cntlm -H, чем аутентифицируйте прокси-сервер corp, отредактируйте файл cntlm.ini с выходом cntlm, перезапустите службу Windows. Обновить .gitconfig с помощью:

[https] proxy = localhost:3128
[http] proxy = localhost:3128

Теперь cntlm выполнит всю аутентификацию, и вы сможете использовать GitHub (и Dropbox, btw) за прокси-сервером corp. По крайней мере, до следующего изменения пароля :) (чем снова cntlm -H)




По моему пониманию ..........

Для начала, поскольку все знают, что прокси означает «авторитет представлять кого-то другого». Теперь есть две вещи: Forward and Reverse proxy.

FORWARD PROXY Предположим, что вы хотите получить доступ к «google» и «google», в свою очередь, будет иметь n количество серверов для ответа на этот конкретный запрос.

Теперь в этом случае, когда вы запрашиваете что-то из Google, и вы не хотите, чтобы google отображал ваш IP-адрес, вы будете использовать прямой прокси-сервер, как описано ниже.

-----> B -----> C

Теперь вы посылаете запрос через B, поэтому C будет думать, что запрос исходит от B, а не A. Таким образом вы можете запретить IP-клиентам своих клиентов не подвергаться внешнему миру.

РЕВЕРСНАЯ ПРОКСИ. Теперь, в этом случае, чтобы вы поняли, мы возьмем тот же случай с прокси-сервером. Здесь вы запросили что-то в google, которое, в свою очередь, отправит один запрос на сервер приложений или другой прокси-сервер, чтобы получить ответ. Так что это произойдет, как объясняется ниже.

-----> B -----> C

          C------>D

          C<------D

A <----- B <----- C На приведенной выше диаграмме вы можете видеть, что запрос был отправлен на C из B, а не из A. После того, как из C будет отправлен один запрос на D. Аналогично, ответ будет отправляться на C из D, а затем в B и A.

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

Прошу прокомментировать, если вы считаете, что приведенное выше объяснение неверно.





github proxy github-for-windows