Генерация паролей в Staqflow: политика, сброс и выдача доступов
В Staqflow есть служебный узел «Генерация пароля»: он создаёт случайное значение по заданной политике и добавляет его к входным данным workflow. Узел подходит как часть процесса сброса пароля, выдачи доступа сотруднику или ротации сервисных аккаунтов. Важно разделять генерацию, проверку запроса на доступ и фактическую запись нового пароля в целевую систему. Ниже — возможности и ограничения, описанные в статье Staqflow от 3 ноября 2026 года.
Как работает узел «Генерация пароля»
Пароли генерируются на сервере Staqflow с помощью криптостойкого генератора случайных чисел операционной системы. Узлу не нужны учётные данные или внешний сервис; запросов наружу для самой генерации нет. Значение остаётся в платформе, пока автор workflow не передаст его следующему сервису.
Для каждого входного элемента формируется отдельный пароль. Результат записывается в заданное поле, остальные поля элемента передаются дальше без изменений. Например, после загрузки таблицы с логинами и адресами каждая строка получит дополнительное поле password, сохранив исходные сведения.
Основные настройки и значения по умолчанию
Длина по умолчанию — 16 символов, допустимый диапазон — от 4 до 256. Строчные буквы a-z, заглавные A-Z и цифры 0-9 включены. Спецсимволы по умолчанию выключены; их набор задаётся в «Параметрах».
Поле результата по умолчанию называется password. Через точку можно указать вложенный путь: это позволяет записать значение внутрь структуры данных. Конкретный путь нужно согласовать с тем, какое поле использует следующий узел.
Минимумы по классам символов
В «Параметрах» задаётся минимальное количество символов каждого включённого класса. По умолчанию требуется по одному символу каждого включённого класса. Например, если принимающая система требует не менее двух цифр и одного спецсимвола, эти минимумы задаются отдельно.
Минимум 0 означает, что класс разрешён, но не обязателен: его символы могут использоваться при дополнении пароля до нужной длины. Сумма обязательных минимумов не должна превышать общую длину.
Спецсимволы и исключения
Собственный набор спецсимволов нужно согласовать с ограничениями принимающей системы. Повторяющийся символ в этом наборе не получает повышенную вероятность выпадения: дубли учитываются.
Опция исключения похожих символов убирает 0, O, o, 1, l, I и вертикальную черту |. Это может быть полезно при ручном вводе или передаче по телефону. Дополнительные исключения позволяют убрать любые нежелательные символы, например кавычки для определённого формата конфигурации. Исключение символов не заменяет корректное экранирование значения при его дальнейшем использовании.
Криптостойкая генерация и проверка политики
Выбор символа выполняется без смещения по модулю: при выборе из набора его символы имеют одинаковую вероятность. Сначала генератор набирает обязательные символы каждого класса, затем дополняет пароль из включённых классов и перемешивает результат. Поэтому обязательная цифра не занимает заранее известную позицию.
Это описание выбора символов и порядка генерации, а не обещание одинаковой вероятности всех возможных строк при любой составной политике. Надёжность процесса также зависит от длины, набора разрешённых символов, способа доставки и защиты целевой учётной записи.
Если политика невыполнима, узел останавливается с ошибкой. Причины: длина вне диапазона 4–256, отсутствие выбранных классов, пустой класс после применения исключений или сумма минимумов больше длины. Например, нельзя требовать спецсимвол, если весь его набор исключён. Сообщение об ошибке указывает, какое ограничение нужно исправить.
Как включить генерацию в сброс пароля
- Выбрать триггер: форму заявки, Telegram-бота поддержки или вебхук сервис-деска.
- Проверить право заявителя на смену пароля этой учётной записи. В источнике предлагается сверить почту или телефон с CRM либо каталогом сотрудников; конкретный способ подтверждения нужно определить для своей системы. Само знание логина или совпадение поля с каталогом не подтверждает личность.
- Добавить «Генерацию пароля» и настроить политику под требования получателя. В статье приведён ориентир 12–16 символов с включёнными спецсимволами и исключением похожих; это пример настройки, а не универсальное требование для всех систем.
- Передать результат в систему учётных записей: узлом LDAP, через HTTP-запрос к API или подходящую интеграцию. Выражение {{ $json.password }} подставляет значение поля результата.
- Доставить временный пароль пользователю по доверенному личному каналу. Если целевая система поддерживает принудительную смену при первом входе, использовать эту возможность.
Генерация сама по себе не меняет пароль в почте, CRM или LDAP: это делает следующий шаг workflow. Ошибки проверки заявителя, записи и доставки нужно обрабатывать на соответствующих этапах процесса.
Сценарии применения
Учётные записи нового сотрудника
Событие из HR-системы может запускать создание аккаунтов в почте, CRM и системе задач. Для разных систем можно использовать несколько узлов с разными полями результата, например mailPassword и crmPassword. Доставка руководителю или сотруднику настраивается отдельным действием, с учётом разрешённых каналов.
Временный доступ подрядчику
Один процесс может создать учётную запись, сгенерировать пароль и записать дату окончания доступа. Другой процесс по расписанию отключает истёкшие аккаунты. Срок действия обеспечивается этими шагами и возможностями целевой системы: генератор не отключает доступ автоматически и не делает пароль одноразовым сам по себе.
Цифровые коды и PIN
Для кода можно оставить только цифры и выбрать длину 4–6. В источнике приведены сценарии шкафчиков, гостевого Wi-Fi и подтверждения выдачи заказа. Ограничение по частоте попыток, срок действия и проверка совпадений — отдельные вопросы процесса и принимающей системы.
Каждый входной элемент получает отдельный результат. Например, 100 строк дадут 100 сгенерированных кодов за запуск. Случайная генерация не означает гарантированную уникальность: если коды должны различаться, нужна отдельная проверка совпадений.
Ротация паролей списком
При загрузке 50 сервисных аккаунтов каждая строка становится входным элементом. Генератор добавляет своё поле password к каждой строке, а следующий узел записывает новые значения в целевую систему. Логины и адреса проходят дальше без изменений.
В статье для сервисных аккаунтов, которые не вводят вручную, указан ориентир 32 символа и более. Верхняя граница узла — 256, но целевая система может принимать меньше: нужно проверить её правила до массового запуска.
Использование в ИИ-агенте
У узла есть вариант «инструмент» для ИИ-агента. Агент может вызвать генерацию по ходу разговора. Параметры политики можно закрепить в настройках узла, чтобы модель их не меняла.
Проверку заявителя и запись пароля в систему удобно вынести в отдельный процесс, вызываемый как инструмент. Сам вызов генератора не подтверждает право человека на доступ и не заменяет разрешения на действия в целевой системе. Для сборки workflow через ИИ-клиент применим MCP; права клиента нужно выдавать под задачу.
Где остаётся пароль после генерации
Сгенерированный пароль является обычным выходом узла и виден в истории запусков. Это существенное отличие от сохранённых ключей интеграций, которые размещаются в учётных данных пространства и не возвращаются через интерфейс и API. Механизм шифрования учётных данных не означает автоматического сокрытия результата генератора.
Процессы сброса паролей следует держать в отдельном пространстве с ограниченным доступом. Выдаваемые людям значения лучше делать временными и требовать смену при первом входе, если система это поддерживает. Не отправлять пароль в общий чат или публичный канал; способ личной доставки нужно выбирать с учётом требований своей организации.
Ключи самих интеграций следует сохранять в предназначенных для них учётных данных. Подробности — в материале о хранении ключей, очистке логов и аудите Staqflow. При проверке первого workflow полезно отдельно оценить вход, результат и условия автоматического запуска — этот порядок разобран в статье об онбординге.
Подробнее о возможностях автоматизации — на сайте Staqflow.