Два вида учётных данных Tableau, выполняющих две разные работы. Одни несут права человека. Другие расширяют возможность платформы. Правильный выбор оставляет модель разрешений, которую вы строили годами, главной в вопросе о том, кто что видит.
Обновлено · 5 мин чтения
Это два пути в два разных места. Считать их взаимозаменяемыми это самая тяжёлая по последствиям ошибка с учётными данными в интеграции с Tableau. Ошибка распространена, потому что работают оба.
Правило здесь записано в коде и сформулировано в модуле, который его реализует. Каждый пользователь входит со своим собственным токеном Tableau. Этот токен несёт его точные права в Tableau. Это граница управления для каждого чтения, каждой записи и каждого вызова ассистента или инструмента, сделанного от его имени.
Вход принадлежит только персональному токену. Путь в один клик, обходивший его, когда-то существовал и был намеренно выведен из эксплуатации. Резолвер удалён, и шлюз теперь отклоняет попытку подключения, имеющую форму JWT.
Причина практическая, а не архитектурная. Позвольте сервисным учётным данным выполнить вход за человека, и каждое действие после этого несёт права сервисной учётной записи, а не человека. Модель разрешений Tableau, которую ваша команда строила годами, перестаёт решать, кто что может видеть.
Она покрывает возможность платформы: человек уже вошёл, а самой платформе нужен собственный токен. Встраивание это живой пример. Настоящее представление Tableau, отрисованное внутри другой поверхности, требует токена, который примет API встраивания, а персональный токен для этого неподходящей формы.
Второй пункт порождает тикеты в поддержку, которые выглядят как нестабильность продукта. Это коллизия учётных данных. Её стоит проверять первой всякий раз, когда запланированная задача и человек, кажется, мешают друг другу.
Секреты в этом пакете живут только в рамках сессии. Это чисто работает, пока что-то не должно запуститься в два часа ночи, когда никто не вошёл. Секрет уровня сессии в этот час по определению существовать не может.
Есть одно исключение, и оно явное, а не подразумеваемое. Оператор нажимает, чтобы закрепить токен для запланированных запусков. Он шифруется при хранении под машинным ключом, никогда не журналируется и никогда не возвращается в браузер. Вызов описания возвращает только имя токена. Один клик его удаляет. Интерфейс рекомендует выделенный токен для автоматизации, по причине коллизии, описанной выше.
Исключение, на которое человек должен нажать, это исключение, которое кто-то сможет потом найти. Исключение, которое происходит автоматически, никто не сможет проверить, и в конце концов никто не вспомнит, что на него соглашался.
Запланированная задача может сначала попробовать персональный токен и откатиться к JWT от Connected App. Это разумный дизайн. Он же может месяцами скрывать сломанные учётные данные, потому что снаружи запуск продолжает удаваться.
Исправление небольшое, и оно важно. Записывайте, какие учётные данные на самом деле прошли аутентификацию, и показывайте это в строке. Откат, который происходит незаметно, это откат, который никто никогда не чинит. Впервые о нём услышат в тот день, когда откат тоже сломается.
Четыре проверки, и на четвёртой стоит не спешить. Всё остальное на этой странице зависит от того, сделана ли она правильно.
Человек уходит. Его имя остаётся на рабочих книгах, расписаниях и подписках, и несколько из них ломаются без единого звука. Чем он владеет, что ломается и порядок, при котором лицензия остаётся восстановимой.
Правило утверждения перед запуском простыми словами. Ассистент читает, объясняет и предлагает, а путь записи принадлежит человеку. Чего это стоит, что это даёт и три вопроса к любой функции ИИ.
Утверждение это предложение. Доказательство это то, что второй человек может проверить, не спрашивая вас. Что должен содержать аудиторский след, что на самом деле доказывает хеш, и чего требовать от любого инструмента, который заявляет, что его создаёт.