OpenID По SSL с сам подписанный сертификат
Для большинства серверов или хостов git вы должны заранее создать репозиторий перед отправкой. Но есть несколько клиентов или серверов, которые могут создавать репозиторий по запросу.
Я слышал, что Github Desktop (клиент для Github) может создавать репозиторий при загрузке, хотя я не могу найти его в документации.
Также, если вы хотите создать репозиторий в Github и не хотите использовать веб-браузер, вы можете создать репозиторий с помощью Github API . Чтобы упростить процесс, я рекомендую использовать оболочку командной строки для API, например, hub .
Gitlab может создать репозиторий на push .
Gitlab также имеет API и множество оболочек командной строки. git repo работает с Github, Gitlab и Bitbucket.
4 ответа
Основное преимущество использования SSL для Вашего OpenID URL - то, что это дает полагающейся стороне механизм, чтобы обнаружить, вмешались ли в DNS. Для полагающейся стороны невозможно сказать, был ли OpenID URL с самоподписанным сертификатом поставлен под угрозу.
Существует другая польза, которую Вы извлекаете из использования SSL на URL конечной точки Вашего поставщика (легче создать ассоциации, никакое подслушивание дополнительных данных), который все еще содержал бы, если бы Вы использовали самоподписанный сертификат, но я полагал бы, что это вторично.
OpenID разработан прозрачным для перенаправления способом. Пока необходимые пары ключ/значение сохраняются при каждом перенаправлении, или ДОБИРАЮТСЯ или POST, все будет работать правильно.
Самое легкое решение достигнуть совместимости с потребителями, которые не работают с самоподписанными сертификатами, состоит в том, чтобы использовать незашифрованную конечную точку, которая перенаправляет checkid_immediate и checkid_setup сообщения к зашифрованному.
Выполнение этого в Вашем серверном коде легче, чем с перенаправлениями веб-сервера, поскольку первый может более легко иметь дело с запросами POST, также держа код вместе. Кроме того, можно использовать ту же конечную точку для обработки всех операций OpenID, независимо должна ли она быть подана по SSL, пока надлежащие проверки сделаны.
Например, в PHP, перенаправление может быть столь же простым как:
// Redirect OpenID authentication requests to https:// of same URL
// Assuming valid OpenID operation over GET
if (!isset($_SERVER['HTTPS']) &&
($_GET['openid_mode'] == 'checkid_immediate' ||
$_GET['openid_mode'] == 'checkid_setup'))
http_redirect("https://{$_SERVER['HTTP_HOST']}{$_SERVER['REQUEST_URI']}");
Как openid.return_to значение было сгенерировано против простой Конечной точки HTTP, что касается потребителя, оно только имеет дело с незашифрованным сервером. Принимая надлежащую операцию OpenID 2.0 с сессиями и данными случаями, независимо от того, что информация передала между потребителем, и Ваш разъединять не должен показывать годную для использования информацию. Операции между Вашим браузером и сервером OpenID, которые являются годными для использования (отслеживание пароля или угон сеансовых куки) сделаны по зашифрованному каналу.
Кроме не допускания соглядатаев, имея операции аутентификации быть выполненным по SSL позволяет Вам использовать secure Флаг cookie HTTP. Это добавляет еще один слой защиты для checkid_immediate операции, должен Вы хотеть позволить его.
(Правовая оговорка: я плохо знаком с OpenID, таким образом, я мог бы быть неправым здесь.) Коммуникация между Открыть ID Consumer (например, StackOverflow) и Открыть ID Provider (Ваш сервер) не требует HTTPS - это будет работать столь же прекрасное и столь же надежно по плоскости HTTP. То, что необходимо сделать, должно настроить сервер для переключения на HTTPS только, когда он показывает Вам Вашу страницу входа в систему. В этом случае только Ваш браузер должен интересоваться самоподписанным сертификатом. Вы могли импортировать сертификат на свой ПК, и все будет так же безопасно как с, скажем, Verisign-выпущенным сертификатом.
Это походит на него. Клиент Вашего сервера OpenID не доверяет корневому центру сертификации.