Прямые доступы к счётчику
Для проверки и выдачи прямого доступа нужен точный логин Яндекса. Начинай с
минимальной роли view; edit выдавай только для задач, где пользователь
действительно должен менять настройки счётчика.
Рабочая последовательность
На вход нужен уже подтверждённый точный логин. Сценарии Метрики не определяют логин самостоятельно.
Создай API-сегмент и сохрани его
segment_id.Проверь прямое разрешение точного логина:
bash scripts/grants.sh --counter 123456 --action get --login client-loginЕсли прямого разрешения нет и вызывающая задача требует его выдать, покажи план минимального доступа:
bash scripts/grants.sh --counter 123456 --action add \ --login client-login --permission view \ --comment "Доступ для использования сегментов"Выполни ту же команду с
--apply. Сценарий сам перечитает разрешение и проверит точное совпадение логина и роли.Для другой роли укажи
--permission analystили--permission edit. Если прямое разрешение уже существует, используй--action update.Верни вызывающей задаче
counter_id,segment_id, логин и подтверждённую роль.
Что можно прочитать
| Данные | Метод API |
|---|---|
| Владелец и собственная роль токена | GET /management/v1/counter/{id} |
| Прямые разрешения | GET /management/v1/counter/{id}/grants |
| Одно прямое разрешение | GET /management/v1/counter/{id}/grant?user_login=... |
| Собственное разрешение | GET /management/v1/counter/{id}/my_grant |
grants.sh --action list выводит владельца отдельно и затем прямые разрешения.
Полный список можно записать явно через --csv; по умолчанию логины не кешируются.
Проверка одного логина использует отдельный метод API. Отсутствующее разрешение
может возвращаться как HTTP 404 или как HTTP 400 с сообщением «нет гранта»;
несуществующий логин тоже даёт HTTP 400, но считается ошибкой, а не отсутствием
доступа.
Список прямых разрешений не равен полному списку всех фактически допущенных пользователей:
- владелец хранится в
owner_login, а не как обычное разрешение; - публичный доступ имеет пустой логин и роль
public_stat; - представители аккаунта получают доступ ко всем его счётчикам и не входят в список прямых разрешений конкретного счётчика;
- для паспортной организации действуют её собственные участники и роли.
Поэтому отсутствие результата у get означает именно отсутствие прямого
разрешения. Справка: доступ к счётчику
и список разрешений API.
Выдача и изменение
| Действие | Метод и путь |
|---|---|
| Выдать | POST /management/v1/counter/{id}/grants |
| Изменить | PUT /management/v1/counter/{id}/grant |
Управлять прямыми разрешениями может владелец (own) или редактор (edit).
Доступные роли команды: view, analyst, edit. Для add роль по умолчанию —
view; для update новую роль нужно выбрать явно через --permission.
Команды add и update без --apply не меняют доступ. Изменяющий
запрос не повторяется автоматически. После неизвестного сетевого результата
сначала выполни get, чтобы не создать лишнее разрешение и не затереть роль.
Для обычных логинов приложению нужны metrika:read и metrika:write. Для работы
от имени логина паспортной организации при выпуске токена также нужен
passport:business.
Если API отвечает 403 с типом counter_in_connect, счётчик связан с паспортной
организацией и изменить разрешение этим методом нельзя — используй веб-интерфейс
организации. Одного права passport:business для обхода ограничения недостаточно.
Фильтры доступа Метрики — отдельный механизм ограничения видимых данных. Этот
сценарий не создаёт и не назначает их, но существующая роль
analyst_access_filter и идентификатор фильтра отображаются при чтении.
Граница результата
Результат этого скилла — созданный API-сегмент Метрики и проверенное прямое разрешение к счётчику. Он не определяет целевой логин и не применяет сегмент во внешних системах.