Skip to main content

Enterprise Server 3.21 в настоящее время доступен в качестве кандидата на выпуск.

Аутентификация как установка приложения GitHub

Вы можете выполнить проверку подлинности GitHub App в качестве установки, чтобы сделать запросы API, влияющие на ресурсы, принадлежащие учетной записи, в которой установлено приложение.

Сведения о проверке подлинности в виде установки GitHub App

После установки данных GitHub App в учетной записи вы можете выполнить проверку подлинности в качестве установки приложения для запросов API. Это позволяет приложению получать доступ к ресурсам, принадлежащим этой установке, если приложению предоставлен необходимый доступ к репозиторию и разрешения. Запросы API, сделанные установкой приложения, относятся к приложению. Для получения дополнительной информации об установке GitHub приложений см. Установка GitHub приложений.

Например, если вы хотите, чтобы приложение изменило Status поле проблемы в проекте, принадлежащей организации с именем "octo-org", вы будете проходить проверку подлинности в качестве установки окто-организации приложения. Временная шкала проблемы указывает, что ваше приложение обновило состояние.

Чтобы выполнить запрос API в качестве установки, необходимо сначала создать маркер доступа к установке. Затем вы отправите маркер доступа к установке в заголовке Authorization последующих запросов API. Вы также можете использовать GitHub, которые могут создать маркер доступа к установке.

Некоторые конечные точки REST API не принимают маркеры доступа к установке, и большинство конечных точек REST API требуют от приложения определенных разрешений на использование конечной точки. Чтобы узнать, принимает ли конечная точка REST API маркеры доступа к установке и чтобы узнать, какие разрешения необходимы, см. в документации по конечной точке.

Установка приложений также может использовать API GraphQL. Как и REST API, приложение должно иметь определенные разрешения для доступа к объектам в API GraphQL. Для запросов GraphQL необходимо проверить наличие у приложения необходимых разрешений для запросов GraphQL и изменений, которые вы хотите сделать.

Вы также можете использовать маркер доступа к установке для проверки подлинности для доступа Git на основе HTTP. Приложение должно иметь разрешение репозитория "Содержимое". Затем можно использовать маркер доступа к установке в качестве пароля HTTP. Замените TOKEN маркером доступа к установке: git clone https://x-access-token:TOKEN@github.com/owner/repo.git

Запросы, сделанные с помощью маркера доступа к установке, иногда называются запросами "сервер — сервер".

Дополнительные сведения о проверке подлинности в качестве приложения от имени пользователя вместо установки приложения см. в разделе Аутентификация с помощью приложения GitHub от имени пользователя.

Использование маркера доступа к установке для проверки подлинности в качестве установки приложения

Чтобы выполнить проверку подлинности в качестве установки с помощью маркера доступа к установке, сначала используйте REST API для создания маркера доступа к установке. Затем используйте этот маркер доступа к установке в заголовке Authorization запроса REST API или API GraphQL. Срок действия маркера доступа к установке истекает через 1 час.

Создание маркера доступа к установке

  1. Создайте веб-токен JSON (JWT) для приложения. Дополнительные сведения см. в разделе Генерация веб-токена JSON (JWT) для приложения GitHub.

  2. Получите идентификатор установки, которую требуется пройти проверку подлинности как.

    Если вы отвечаете на событие веб-перехватчика, полезные данные веб-перехватчика будут содержать идентификатор установки.

    Вы также можете использовать REST API для поиска идентификатора для установки приложения. Например, вы можете получить идентификатор установки с GET /users/{username}/installation, GET /repos/{owner}/{repo}/installation``GET /orgs/{org}/installationили GET /app/installations конечными точками. Дополнительные сведения см. в разделе Конечные точки REST API для GitHub Apps.

    Вы также можете найти идентификатор приложения на странице параметров приложения. Идентификатор приложения отличается от идентификатора клиента. Для получения дополнительной информации о переходе на страницу настроек GitHub Appдля вашего , смотрите АВТОЗАГОЛОВОК.

  3. Отправьте запрос REST API POST в /app/installations/INSTALLATION_ID/access_tokens. Добавьте веб-токен JSON в Authorization заголовок запроса. Замените INSTALLATION_ID идентификатором установки, которую требуется пройти проверку подлинности.

    Например, отправьте этот запрос curl. Замените INSTALLATION_ID идентификатором установки и JWT веб-маркером JSON:

    curl --request POST \
    --url "http(s)://HOSTNAME/api/v3/app/installations/INSTALLATION_ID/access_tokens" \
    --header "Accept: application/vnd.github+json" \
    --header "Authorization: Bearer JWT" \
    --header "X-GitHub-Api-Version: 2026-03-10"
    

    При необходимости можно использовать repositories параметры или repository_ids параметры тела для указания отдельных репозиториев, к которым может получить доступ маркер доступа к установке. Если вы не используете repositories или repository_ids не предоставляете доступ к определенным репозиториям, маркер доступа к установке будет иметь доступ ко всем репозиториям, к которым была предоставлена установка. Маркер доступа к установке не может быть предоставлен доступ к репозиториям, к которым установка не была предоставлена. Вы можете перечислить до 500 репозиториев.

    При необходимости используйте permissions параметр body, чтобы указать разрешения, которые должен иметь маркер доступа установки. Если permissions это не указано, маркер доступа к установке будет иметь все разрешения, предоставленные приложению. Маркер доступа к установке не может быть предоставлен разрешениям, которым приложение не было предоставлено.

    Ответ будет включать маркер доступа к установке, время истечения срока действия маркера, разрешения, имеющиеся маркером, и репозитории, к которым маркер может получить доступ, если это применимо. Срок действия маркера доступа к установке истекает через 1 час.

    Дополнительные сведения об этой конечной точке см. в разделе Конечные точки REST API для GitHub Apps.

    Примечание.

    В большинстве случаев передать маркер с помощью Authorization: Bearer или Authorization: token. Однако при передаче веб-токена JSON (JWT) необходимо использовать Authorization: Bearer.

Проверка подлинности с помощью маркера доступа к установке

Чтобы пройти проверку подлинности с помощью маркера доступа к установке, добавьте его в Authorization заголовок запроса API. Маркер доступа будет работать как с API GraphQL, так и с REST API.

Приложение должно иметь необходимые разрешения для использования конечной точки. Дополнительные сведения см. в разделе Выбор разрешений для приложения GitHub.

В следующем примере замените INSTALLATION_ACCESS_TOKEN маркер доступа на установку:

curl --request GET \
--url "http(s)://HOSTNAME/api/v3/meta" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer INSTALLATION_ACCESS_TOKEN" \
--header "X-GitHub-Api-Version: 2026-03-10"

Использование пакета SDK Octokit.js для проверки подлинности в качестве установки приложения

Для проверки подлинности в качестве установки приложения можно использовать пакет SDK Octokit.js GitHub. Одним из преимуществ использования пакета SDK для проверки подлинности является то, что вам не нужно создавать веб-токен JSON (JWT) самостоятельно. Кроме того, пакет SDK будет заботиться о повторном создании маркера доступа к установке, поэтому вам не нужно беспокоиться о истечении одного часа.

Примечание.

Чтобы использовать библиотеку Octokit.js, необходимо установить и импортировать octokit ее. В следующем примере используются инструкции импорта в соответствии с ES6. Дополнительные сведения о различных методах установки и импорта см . в разделе об использовании Octokit.js README.

Использование Octokit.js для проверки подлинности с помощью идентификатора установки

  1. Получите идентификатор данных GitHub App. Идентификатор приложения можно найти на странице параметров для GitHub App. Дополнительные сведения о переходе на страницу параметров для GitHub Appсм. в разделе Изменение регистрации приложения GitHub.

  2. Создайте закрытый ключ. Дополнительные сведения см. в разделе Управление приватными ключами для приложений GitHub.

  3. Получите идентификатор установки, которую требуется пройти проверку подлинности как.

    Если вы отвечаете на событие веб-перехватчика, полезные данные веб-перехватчика будут содержать идентификатор установки.

    Вы также можете использовать REST API для поиска идентификатора для установки приложения. Например, можно получить идентификатор установки с GET /users/{username}/installationпомощью конечных точек или GET /repos/{owner}/{repo}/installation конечных GET /orgs/{org}/installation``GET /app/installationsточек. Дополнительные сведения см. в разделе Конечные точки REST API для GitHub Apps.

  4. Импорт App из octokit. Создайте новый экземпляр класса App. В следующем примере замените APP_ID ссылку на идентификатор приложения. Замените PRIVATE_KEY ссылкой на закрытый ключ приложения.

    JavaScript
    import { App } from "octokit";
    
    const app = new App({
      appId: APP_ID,
      privateKey: PRIVATE_KEY,
    });
    
  5.        `getInstallationOctokit` Используйте метод для создания экземпляра, прошедшего проверку подлинности`octokit`. В следующем примере замените `INSTALLATION_ID` идентификатором установки приложения, от имени которого требуется выполнить проверку подлинности.
    
    JavaScript
    const octokit = await app.getInstallationOctokit(INSTALLATION_ID);
    
  6.        `octokit` Используйте метод для выполнения запроса к API.
    

    Приложение должно иметь необходимые разрешения для использования конечной точки. Дополнительные сведения см. в разделе Выбор разрешений для приложения GitHub.

    Например, чтобы запросить API GraphQL:

    JavaScript
    await octokit.graphql(`
      query {
        viewer {
          login
        }
      }
      `)
    

    Например, чтобы выполнить запрос к REST API:

    JavaScript
    await octokit.request("GET /meta")
    

Использование Octokit.js для проверки подлинности в ответ на событие веб-перехватчика

Пакет SDK Octokit.js также передает предварительно прошедший проверку подлинности octokit экземпляр обработчикам событий веб-перехватчика.

  1. Получите идентификатор данных GitHub App. Идентификатор приложения можно найти на странице параметров для GitHub App. Дополнительные сведения о переходе на страницу параметров для GitHub Appсм. в разделе Изменение регистрации приложения GitHub.

  2. Создайте закрытый ключ. Дополнительные сведения см. в разделе Управление приватными ключами для приложений GitHub.

  3. Получите секрет веб-перехватчика, указанный в параметрах приложения. Дополнительные сведения о секретах веб-перехватчика см. в разделе Использование вебхуков с приложениями GitHub.

  4. Импорт App из octokit. Создайте новый экземпляр класса App. В следующем примере замените APP_ID ссылку на идентификатор приложения. Замените PRIVATE_KEY ссылкой на закрытый ключ приложения. Замените WEBHOOK_SECRET секрет веб-перехватчика приложения.

    JavaScript
    import { App } from "octokit";
    
    const app = new App({
      appId: APP_ID,
      privateKey: PRIVATE_KEY,
      webhooks: { WEBHOOK_SECRET },
    });
    
  5.        `app.webhooks.*` Используйте метод для обработки событий веб-перехватчика. Дополнительные сведения см [. в разделе](https://github.com/octokit/octokit.js#webhooks) веб-перехватчиков README Octokit.js. Например, чтобы создать комментарий о проблеме при открытии проблемы:
    
    app.webhooks.on("issues.opened", ({ octokit, payload }) => {
      await octokit.request("POST /repos/{owner}/{repo}/issues/{issue_number}/comments", {
          owner: payload.repository.owner.login,
          repo: payload.repository.name,
          issue_number: payload.issue.number,
          body: `This is a bot post in response to this issue being opened.`,
          headers: {
            "x-github-api-version": "2026-03-10",
          },
        }
      )
    });