Предупреждение
Обратитесь к маркерам доступа, таким как пароли. Для получения дополнительной информации см . раздел «Обеспечение безопасности вашего personal access tokens».
О personal access tokens
Personal access tokens являются альтернативой использованию паролей для аутентификации при GitHubиспользованииGitHub API или командной строки.
Personal access tokenS предназначены для доступа к GitHub ресурсам от вашего имени. Чтобы получить доступ к ресурсам от имени организации или для долгосрочных интеграций, следует использовать GitHub App. Дополнительные сведения см. в разделе О создании приложений GitHub.
Маркер имеет те же возможности для доступа к ресурсам и выполнения действий с этими ресурсами, которые владелец маркера имеет, и дополнительно ограничивается любыми областями или разрешениями, предоставленными маркеру. Маркер не может предоставить пользователю дополнительные возможности доступа. Например, a personal access token может быть настроен с admin:org областью применения, но если владелец токена не является владельцем организации, токен не предоставит административный доступ организации.
Типы personal access token
GitHub В настоящее время поддерживает два типа personal access tokenS: fine-grained personal access tokenS и personal access tokens (classic). GitHub Рекомендует использовать fine-grained personal access tokenS вместо personal access tokens (classic) S, когда это возможно.
Примечание.
Fine-grained personal access tokenS, хотя и более надёжны и контролируемы, не могут выполнить все задачи, которые могут выполнить A personal access token (classic) . Смотрите раздел о Fine-grained personal access tokens ограничениях ниже, чтобы узнать больше.
Оба s fine-grained personal access tokenи personal access tokens (classic) связаны с пользователем, который их сгенерировал, и станут неактивными, если пользователь потеряет доступ к ресурсу.
Владельцы организаций могут установить политику, ограничивающую доступ personal access tokens (classic) к своей организации. Дополнительные сведения см. в разделе Настройка политики личного маркера доступа для вашей организации.
Fine-grained personal access tokens
Fine-grained personal access tokens У них есть несколько преимуществ personal access tokens (classic)в безопасности, но также есть ограничения, которые могут помешать вам использовать их в любой ситуации. Эти ограничения и наши планы по их устранению см. в разделе ниже.
Если вы сможете использовать A fine-grained personal access token для своего сценария, вы получите пользу от следующих улучшений:
- Каждый маркер ограничен доступом к ресурсам, принадлежащим одному пользователю или организации.
- Каждый маркер может быть ограничен только определенными репозиториями для этого пользователя или организации.
- Каждому токена предоставляются конкретные, детализированные разрешения, которые дают больше контроля, чем область применения, предоставленная personal access tokens (classic).
- Владельцы организаций могут потребовать одобрение для любых fine-grained personal access tokenорганизаций, имеющих доступ к ресурсам организации.
Fine-grained personal access tokens Ограничения
Fine-grained personal access tokensНе поддерживайте все функции .personal access tokens (classic) Эти пробелы в особенностях не постоянны — GitHub он работает над их закрытием. Вы можете просмотреть нашу общедоступную стратегию для получения дополнительных сведений о том, когда эти сценарии будут поддерживаться.
Основные пробелы в fine-grained personal access tokens следующие:
-
Используется fine-grained personal access token для внесения вклада в публичные репозитории, где пользователь не является участником.
-
Используется fine-grained personal access token для внесения вклада в репозитории, где пользователь является внешним или репозиториевым соавтором.
-
Использовать fine-grained personal access token доступ к нескольким организациям одновременно.
-
Использование fine-grained personal access token для доступа к пакетам.
-
Использую fine-grained personal access token вызов API проверок.
-
Используйте fine-grained personal access token доступ к проектам, принадлежащим пользовательской учетной записи.
Все эти пробелы будут устранены со временем, поскольку GitHub мы продолжаем инвестировать в более безопасные модели доступа.
Personal access tokens (classic)
Personal access tokens (classic) менее безопасны. Однако некоторые функции в настоящее время будут работать только с personal access tokens (classic):
- Только personal access tokens (classic) имеют доступ на запись для общедоступных репозиториев, которые не принадлежат вам или организации, в которую вы не входите.
- Внешние сотрудники могут использовать только personal access tokens (classic) для доступа к репозиториям организации, над которыми они находятся.
- Несколько конечных точек REST API доступны только с помощью personal access tokens (classic). Чтобы проверить, поддерживает ли конечная точка fine-grained personal access tokens, ознакомьтесь с документацией по этой конечной точке или см. раздел AUTOTITLE.
Если вы решите использовать personal access token (classic), имейте в виду, что он предоставит доступ ко всем репозиториям внутри организаций, к которым у вас есть доступ, а также ко всем личным репозиториям в вашем личном аккаунте.
В качестве меры предосторожности GitHub автоматически удаляет personal access token, которые не использовались в течение года. Чтобы обеспечить дополнительную безопасность, настоятельно рекомендуется добавить срок действия в personal access tokens.
Как сохранить свою personal access tokenбезопасность
Personal access tokenS — это как пароли, и они несут одинаковые врождённые риски безопасности. Перед созданием нового personal access tokenаккаунта подумайте, есть ли более безопасный способ аутентификации:
- Чтобы получить доступ GitHub из командной строки, можно использовать GitHub CLI или Git Credential Manager вместо создания personal access token.
- При использовании personal access token a в рабочем GitHub Actions процессе подумайте, можно ли использовать встроенный
GITHUB_TOKENпроцесс. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.
Если эти варианты невозможны, и вам нужно создать personal access token, рассмотрите возможность использования другого сервиса CLI для безопасного хранения вашего токена.
При использовании a personal access token в скрипте вы можете хранить свой токен как секрет и запускать скрипт через GitHub Actions. Для получения дополнительной информации см. Использование секретов в GitHub Actions. Вы также можете хранить свой токен в Codespaces секрете и запускать скрипт в Codespaces. Для получения дополнительной информации см. Управление секретами, специфичными для ваших аккаунтов, для GitHub Codespaces.
Дополнительные сведения о рекомендациях см. в разделе Обеспечение безопасности учетных данных API.
Создание fine-grained personal access token
Примечание.
Есть лимит в 50 fine-grained personal access tokens штук, которые можно создать. Если вам нужно больше токенов или вы строите автоматизации, рассмотрите возможность использования A GitHub App для лучшей масштабируемости и управления. Дополнительные сведения см. в разделе Решение о том, когда создавать приложение GitHub.
-
Проверьте свой адрес электронной почты, если он ещё не был проверен.
-
В правом верхнем углу любой страницы на GitHubщелкните рисунок профиля, а затем выберите октикона "шестеренка" aria-hidden="true" aria-label="gear" %} Settings.
-
На левой боковой панели щелкните Параметры разработчика.
-
В левой боковой панели, под Personal access tokens, нажмите Тонкозернистые жетоны.
-
Нажмите кнопку "Создать новый маркер".
-
В разделе "Имя токена" введите имя маркера.
-
В разделе "Срок действия" выберите срок действия маркера. Бесконечное время существования разрешено, но может быть заблокировано максимальной политикой времени существования, установленной вашей организацией или владельцем предприятия. Для получения дополнительной информации см. раздел «Обеспечение применения максимальной пожизненной политики» для personal access tokens.
-
При необходимости в разделе "Описание" добавьте заметку, чтобы описать назначение маркера.
-
В разделе "Владелец ресурса" выберите владельца ресурса. Маркер сможет получить доступ только к ресурсам, принадлежащим выбранному владельцу ресурса. Организации, членом которых вы являетесь, не появятся, если организация заблокировала использование fine-grained personal access tokens. Для получения дополнительной информации см. Настройка политики личного маркера доступа для вашей организации.
-
Опционально, если владелец ресурса — организация, требующая одобрения для fine-grained personal access tokens, ниже владельца ресурса в поле введите обоснование запроса.
-
В разделе "Доступ к репозиторию" выберите репозитории, к которым требуется получить доступ. Вы должны выбрать минимальный доступ к репозиторию, соответствующий вашим потребностям. Токены всегда включают доступ только для чтения ко всем публичным репозиториям на GitHub.
-
Если вы выбрали только репозитории на предыдущем шаге, в раскрывающемся списке "Выбранные репозитории " выберите репозитории, к которым требуется получить доступ маркера.
-
В разделе "Разрешения" выберите разрешения для предоставления маркера. В зависимости от того, какой владелец ресурса и какой доступ к репозиторию вы указали, существуют разрешения репозитория, организации и учетной записи. Вы должны выбрать минимальные разрешения, необходимые для ваших потребностей.
В справочном документе REST API для каждого конечного пункта указано, работает ли конечная точка с fine-grained personal access tokenS, и указывает, какие разрешения необходимы для использования токена. Для некоторых конечных точек может потребоваться несколько разрешений, а для некоторых конечных точек может потребоваться одно из нескольких разрешений. Для обзора того, к которым REST API fine-grained personal access token может получить доступ с каждым разрешением, см. Разрешения, необходимые для подробных персональных маркеров доступа.
-
Щелкните Создать токен.
Если вы выбрали организацию в качестве владельца ресурса и организация требует одобрения для fine-grained personal access tokens, то ваш токен будет отмечен как pending до тех пор, пока его не проверит администратор организации. Маркер сможет читать общедоступные ресурсы только до тех пор, пока он не будет утвержден. Если вы являетесь владельцем организации, ваш запрос автоматически утвержден. Дополнительные сведения см. в разделе Просмотр и отзыв персональных маркеров доступа в организации.
Предварительное заполнение fine-grained personal access token данных с использованием параметров URL
Вы можете делиться шаблонами через fine-grained personal access token ссылки. Направляя пользователей к созданию токенов с уже выполненными соответствующими полями, вы облегчаете автоматизацию рабочих процессов и улучшаете опыт разработчиков.
Каждое поддерживаемое поле можно задать с помощью определенного параметра запроса. Все параметры являются необязательными и проверяются формой генерации токена, чтобы комбинации разрешений и владельца ресурса имели смысл.
Вот пример шаблона URL с разрывами строк для читаемости:
https://github.com/settings/personal-access-tokens/new ?name=Repo-reading+token &description=Just+contents:read &target_name=octodemo &expires_in=45 &contents=read
https://github.com/settings/personal-access-tokens/new
?name=Repo-reading+token
&description=Just+contents:read
&target_name=octodemo
&expires_in=45
&contents=read
Попробуйте создать маркер с contents:read``metadata:readуказанным именем и описанием и датой окончания срока действия 45 дней в будущем. Появится сообщение об ошибке, Cannot find the specified resource owner: octodemo указывающее, что вы не являетесь членом octodemo организации.
Ниже приведены некоторые примеры URL-адресов, которые создают маркеры, которые мы видим чаще всего:
- Читать содержимое репозитория
- Push-доступ к репозиториям
- GitHub Models доступ
- Обновите код и откройте pull request
- Управление Copilot лицензиями в организации
- Сделать запросы Copilot
Поддерживаемые параметры запроса
Чтобы создать собственный шаблон токена, следуйте сведениям о параметре запроса, указанным в этой таблице:
| Parameter | Тип | Пример значения | Допустимые значения | Description |
|---|---|---|---|---|
name | струна | Deploy%20Bot | ≤ 40 символов, закодированных URL-адресом | Заранее заполняет отображаемое имя токена. |
description | струна | Used+for+deployments | ≤ 1024 символов, закодированных URL-адресом | Предварительно заполняет описание маркера. |
target_name | струна | octodemo | Слизь пользователя или организации | Задает целевой объект ресурса маркера. Это владелец репозиториев, к которым маркер сможет получить доступ. Если это не указано, по умолчанию используется учетная запись текущего пользователя. |
expires_in | Целое число | |||
30 или none | Целое число от 1 до 366 или none | Дни до истечения срока действия или none истечения срока действия. Если это не указано, значение по умолчанию равно 30 дней или меньше, если целевой объект имеет набор политик времени существования маркера. | ||
<permission> | струна | contents=read | Ряд уровней разрешений и доступа. | Разрешения, которые должен иметь маркер. Разрешения могут быть заданы readкак , writeили admin, но не все разрешения поддерживают каждый из этих уровней. |
Разрешения
Для установки разрешения используйте его имя как параметр запроса, при этом значение указывает желаемый уровень доступа. Допустимые уровни доступа — , и , но не все разрешения поддерживают все уровни — некоторые только read-только, некоторые writeтолько -, и лишь немногие принимают admin.admin``write``read
Объедините несколько прав в форме &contents=read&pull_requests=write&..., используя столько раз, сколько нужно.
Совет
Вам не нужно включать оба варианта и write для разрешения в вашем URL — write всегда включает read, и admin всегда включает write.read
Разрешения учетной записи
Внимание
Права учетной записи можно использовать только если текущий пользователь является владельцем ресурса.
| Имя параметра | Показать имя | Уровни доступа |
|---|---|---|
blocking | Блокировать другого пользователя | |
read, write | ||
codespaces_user_secrets | ||
| Codespaces Пользовательские секреты | ||
read, write | ||
copilot_messages | Копилот Чат | read |
copilot_editor_context | ||
| Copilot Контекст редактора | read | |
copilot_requests | ||
| Copilot запросов | write | |
emails | Адреса электронной почты | |
read, write | ||
user_events | События | read |
followers | Подписчики | |
read, write | ||
gpg_keys | Ключи GPG | |
read, write | ||
gists | Gist | write |
keys | Ключи SSH Git | |
read, write | ||
interaction_limits | Ограничения взаимодействия | |
read, write | ||
knowledge_bases | Базы знаний | |
read, write | ||
user_models | Models | read |
plan | Plan | read |
private_repository_invitations | Приглашения к частному репозиторию | read |
profile | Profile | write |
git_signing_ssh_public_keys | Ключи подписывания SSH | |
read, write | ||
starring | Добавление в избранное | |
read, write | ||
watching | Просмотр | |
read, write |
Примечание.
Разрешение copilot_requests позволяет делать Copilot запросы для конкретного пользователя. Эти запросы засчитываются в норму на премиальные запросы пользователя. Дополнительные запросы, выходящие за рамки пособия, требуют выставления счетов за свыше возраста. Для получения дополнительной информации о Copilot запросах и выставлении счетов см. Запросы в GitHub Copilot (наследие).
Разрешения репозитория
Разрешения репозитория работают как для владельцев ресурсов пользователей, так и для организаций.
| Имя параметра | Показать имя | Уровни доступа |
|---|---|---|
actions | Действия | |
read, write | ||
administration | Администрация | |
read, write | ||
artifact_metadata | Метаданные артефакта | |
read, write | ||
attestations | Attestations | |
read, write | ||
code_quality | Качество кода | |
read, write | ||
security_events | Оповещения о проверке кода | |
read, write | ||
codespaces | Codespaces | |
read, write | ||
codespaces_lifecycle_admin | ||
| Codespaces Администрирование жизненного цикла | ||
read, write | ||
codespaces_metadata | ||
| Codespaces Метаданные | read | |
codespaces_secrets | ||
| Codespaces Секреты | write | |
statuses | Состояния фиксаций | |
read, write | ||
contents | Содержимое | |
read, write | ||
repository_custom_properties | Пользовательские свойства | |
read, write | ||
vulnerability_alerts | Dependabot alerts | |
read, write | ||
dependabot_secrets | Секреты Dependabot | |
read, write | ||
deployments | Развертывания | |
read, write | ||
discussions | Обсуждения | |
read, write | ||
environments | Environments | |
read, write | ||
issues | Проблемы | |
read, write | ||
merge_queues | Объединение очередей | |
read, write | ||
metadata | Metadata | read |
pages | Страницы | |
read, write | ||
pull_requests | Запросы на слияние | |
read, write | ||
repository_advisories | Рекомендации по безопасности репозитория | |
read, write | ||
secret_scanning_alerts | ||
| Secret scanning Оповещения | ||
read, write | ||
secrets | Secrets | |
read, write | ||
actions_variables | Переменные | |
read, write | ||
repository_hooks | Webhooks | |
read, write | ||
workflows | Workflows | write |
Разрешения организации
Внимание
Разрешения организации можно использовать только в том случае, если владелец ресурса является организацией.
| Имя параметра | Показать имя | Уровни доступа |
|---|---|---|
organization_api_insights | Аналитика API | read |
organization_administration | Администрация | |
read, write | ||
organization_user_blocking | Блокировка пользователей | |
read, write | ||
organization_campaigns | Кампании | |
read, write | ||
organization_custom_org_roles | Пользовательские роли организации | |
read, write | ||
organization_custom_properties | Настраиваемые свойства репозитория | |
read, , write``admin | ||
organization_custom_roles | Пользовательские роли репозитория | |
read, write | ||
organization_events | События | read |
organization_copilot_seat_management | GitHub Copilot для бизнеса | |
read, write | ||
issue_types | Типы проблем | |
read, write | ||
organization_knowledge_bases | Базы знаний | |
read, write | ||
members | Members | |
read, write | ||
organization_models | Models | read |
organization_network_configurations | Конфигурации сети | |
read, write | ||
organization_announcement_banners | Баннеры объявлений организации | |
read, write | ||
organization_codespaces | Организация Codespaces | |
read, write | ||
organization_codespaces_secrets | Тайны организации Codespaces | |
read, write | ||
organization_codespaces_settings | Организационные Codespaces условия | |
read, write | ||
organization_dependabot_secrets | Тайны организации Dependabot | |
read, write | ||
organization_code_scanning_dismissal_requests | Запросы на увольнение организации для code scanning | |
read, write | ||
organization_private_registries | Частные реестры организаций | |
read, write | ||
organization_plan | Plan | read |
organization_projects | Projects | |
read, , write``admin | ||
organization_secrets | Secrets | |
read, write | ||
organization_self_hosted_runners | Самостоятельно размещенные агенты | |
read, write | ||
team_discussions | Обсуждения в команде | |
read, write | ||
organization_actions_variables | Переменные | |
read, write | ||
organization_hooks | Webhooks | |
read, write |
Создание personal access token (classic)
Примечание.
Владельцы компаний могут ограничить доступ personal access token (classic) к своей организации. Если вы попытаетесь использовать personal access token (classic) a для доступа к ресурсам в организации, где отключён personal access token (classic) доступ, ваш запрос провалится с ответом 403. Вместо этого нужно использовать GitHub App, OAuth app, или fine-grained personal access token.
Предупреждение
Вы можете получить доступ ко personal access token (classic) всем репозиториям, к которым доступны. GitHub Рекомендует использовать fine-grained personal access tokenS, который можно ограничить определёнными репозиториями. Fine-grained personal access tokenS также позволяют указывать детализированные права вместо широких сфер доступа.
-
Проверьте свой адрес электронной почты, если он ещё не был проверен.
-
В правом верхнем углу любой страницы на GitHubщелкните рисунок профиля, а затем выберите октикона "шестеренка" aria-hidden="true" aria-label="gear" %} Settings.
-
На левой боковой панели щелкните Параметры разработчика.
-
В левой боковой панели, под Personal access tokens, нажмите Tokens (classic).
-
Выберите "Создать новый маркер", а затем нажмите кнопку "Создать новый маркер" (классическая модель).
-
В поле "Примечание" присвойте маркеру описательное имя.
-
Чтобы предоставить маркер срок действия, выберите "Срок действия", а затем выберите параметр по умолчанию или нажмите кнопку "Пользовательский" , чтобы ввести дату.
-
Выберите области, которые вы хотите предоставить этому маркеру. Чтобы использовать маркер для доступа к репозиториям из командной строки, выберите repo. С помощью маркера без назначенных областей можно получить доступ только к общедоступной информации. Дополнительные сведения см. в разделе Области для приложений OAuth.
-
Щелкните Создать токен.
-
По необходимости, чтобы скопировать новый токен в буфер обмена, нажмите .
- Чтобы использовать маркер для доступа к ресурсам, принадлежащим организации, использующей единый вход SAML, авторизации маркера. Для получения дополнительной информации смотрите Авторизация личного маркера доступа для использования с единым входом в GitHub Enterprise Cloud документации...
Удаление personal access token
Если он больше не нужен, следует удалить personal access token . Если вы удалите ключ personal access token , который использовался для создания ключа развертывания, ключ развертывания также будет удален.
- В правом верхнем углу любой страницы на GitHubщелкните рисунок профиля, а затем выберите октикона "шестеренка" aria-hidden="true" aria-label="gear" %} Settings.
- На левой боковой панели щелкните Параметры разработчика.
- В левой боковой панели, под Personal access tokens, нажмите либо Fine-grained tokens , либо Tokens (classic), в зависимости от того personal access token , какой тип вы хотите удалить.
- Справа от нужного personal access token удалить нажмите «Удалить».
[!NOTE] Если вы обнаружите утечку personal access token , принадлежащую кому-то другому, вы можете подать запрос на отзыв через REST API. См . раздел AUTOTITLE.
Использование personal access token кнопки в командной строке
Когда у вас есть personal access token, вы можете ввести его вместо пароля при выполнении операций с Git через HTTPS.
Например, чтобы клонировать репозиторий в командной строке, введите следующую git clone команду. Затем вам будет предложено ввести имя пользователя и пароль. Если вас запросят пароль, введите «в» personal access token вместо пароля.
$ git clone https://github.com/USERNAME/REPO.git
Username: YOUR-USERNAME
Password: YOUR-PERSONAL-ACCESS-TOKEN
Хотя вы обязаны ввести своё имя пользователя вместе personal access tokenс , это имя пользователя не используется для аутентификации. Вместо этого используется personal access token для подтверждения вашей подлинности. Если вы не вводите имя пользователя, вы получите сообщение об ошибке о том, что учетные данные недопустимы.
Personal access tokens можно использовать только для операций с HTTPS Git. Если в репозитории используется удаленный URL-адрес SSH, необходимо переключить удаленный узел с SSH на HTTPS.
Если вам не предлагается ввести имя пользователя и пароль, ваши учетные данные, возможно, кэшированы на компьютере. Вы можете обновить учетные данные в цепочке ключей, чтобы заменить старый пароль маркером.
Вместо ручного ввода personal access token для каждой операции HTTPS Git можно кэшировать personal access token с помощью Git-клиента. Git временно хранит учетные данные в памяти до истечения срока их действия. Вы также можете сохранить маркер в обычном текстовом файле, который Git может считывать перед каждым запросом. Дополнительные сведения см. в разделе Кэширование учетных данных GitHub в Git.