Как мы построили IAM для Telegram на Telethon и автоматизировали управление сотней корпоративных чатов
Django принимает кадровое событие и создаёт операцию в PostgreSQL, а отдельный долгоживущий worker через Telethon выполняет запросы к Telegram MTProto API. Очередь хранится в базе: worker использует lease, heartbeat, повторные попытки и SELECT ... FOR UPDATE SKIP LOCKED, поэтому незавершённую операцию можно восстановить после сбоя. Результат хранится по каждому чату, и повторно обрабатываются только проблемные цели.
Сотрудников связывают с Telegram по подтверждённому телефону, сохраняя user ID и access hash; совпадения по имени или username не используются. Модуль различает обычные группы, супергруппы и каналы, учитывает миграцию между ними и после RPC проверяет фактическое членство пользователя. Удаление построено как идемпотентное desired state: если сотрудника уже нет в группе, операция считается успешной.
Служебная учётная запись отделена от личных аккаунтов, получает минимальные права и использует зашифрованную StringSession. Администратор видит очередь, heartbeat, историю, ошибки прав, FloodWait и частичные результаты, а offboarding считается завершённым только после проверки всех чатов, включённых в обязательную политику доступа.
Коротко
- Web-приложение не подключается к Telegram: оно создаёт операцию в PostgreSQL, а MTProto-запросы выполняет отдельный Telethon worker.
- Идемпотентность защищает от повторных HR-событий и двойных нажатий: одинаковый внешний идентификатор не создаёт новую операцию.
- Обычные группы, супергруппы и каналы требуют разных MTProto-запросов, а миграция группы меняет peer ID и доступные операции.
- Успешный RPC не считается достаточным: после приглашения или удаления система отдельно проверяет фактическое членство пользователя.
- Телефоны, access hash, API hash, StringSession и данные 2FA не попадают в логи, а production-сессия хранится в зашифрованном виде.
FAQ
Зачем компании отдельный IAM-модуль для Telegram, если сотрудников можно добавлять и удалять из корпоративных чатов вручную?
Ручной процесс трудно проверить: сотрудника можно удалить из десятков групп и незаметно пропустить одну. Модуль фиксирует результат по каждому обязательному чату и показывает частичные ошибки.
Почему управление чатами вынесли в отдельный Telethon worker, а не выполняют напрямую внутри Django-приложения?
Telethon требует долгоживущего асинхронного соединения, тогда как web-процессы обрабатывают короткие запросы и могут перезапускаться. Отдельный worker сохраняет соединение и восстанавливает операции через очередь.
Как система связывает корпоративного сотрудника с его Telegram-аккаунтом и избегает ошибочных совпадений?
Основным ключом служит нормализованный телефон, а связь создаётся только при единственном однозначном совпадении. Имя и username не используются как автоматические критерии.
Читайте также
Бот в MAX молчит: четыре проблемы Bot API, о которых не пишут в документации- Как мы описали 15 000 таблиц за полгода вместо 500 за год и перестали писать документацию вручную
- Ошибки не должны быть безмолвными: Sentry, Firebase Crashlytics и Datadog в одном Flutter-приложении
- Как распознать речь из видео и аудио: короткая инструкция по транскрибации для новичков
Зрители стали лояльнее к рекламе в стриминге
- Вынос MTProto-клиента из web-процесса: Долгоживущий Telegram-клиент нельзя безопасно размещать внутри Django, Gunicorn или другого многопроцессного web-приложения. Web-слой должен только создавать операцию, а отдельный worker — владеть соединением с Telegram, выполнять запросы и сохранять результат.
[Архитектура интеграций]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Федеральная девелоперская компания «РАЗУМ» построила IAM-модуль для управления почти сотней корпоративных чатов Telegram. Система автоматически добавляет новых сотрудников, удаляет уволенных и фиксирует результат отдельно по каждой группе.