Мини-приложения Telegram

Происхождение и развитие

Исторический анонс Telegram от 16 апреля 2022 года описывает появление у ботов гибких интерфейсов на JavaScript. Пользователь мог выбирать элементы внутри полноценного окна, а не ограничиваться перепиской. Команда демонстрировала подход на вымышленном заказе еды в DurgerKingBot. Это свидетельство развития формата, а не доказательство первого употребления названия Mini Apps. ^[5]

Дальнейшее развитие затронуло вход в приложение: 31 июля 2024 года документация зафиксировала Main Mini App — основное мини-приложение, запускаемое из профиля бота. ^[1] Поэтому историю формата полезно понимать как расширение интерфейса и способов доступа, а не как появление самостоятельной операционной системы.

Как устроено приложение

У интерфейса внутри Telegram и обслуживающего его сервера разные задачи. По условиям платформы сторонние приложения размещаются на серверах разработчиков. ^[3] На экране человек выбирает действие; серверная часть обрабатывает запрос. В учебном сервисе выдачи подборок именно она должна решить, какой материал доступен данному читателю.

Если выбранный способ запуска предоставляет данные пользователя, их проверяют через строку initData. Её отправляют серверу и проверяют по документированной криптографической схеме — математическому способу обнаружить подмену. Поле auth_date позволяет проверить давность данных. initDataUnsafe содержит разобранные входные данные, которым документация запрещает доверять без проверки. ^[1]

Однако достоверный идентификатор пользователя ещё не даёт ему права на любой материал. OWASP, проект рекомендаций по безопасности приложений, различает аутентификацию — проверку личности — и авторизацию — проверку разрешённого действия. Например, читатель может войти в сервис, но не иметь доступа к редакторскому разделу. Проверку прав выполняют на серверной стороне для каждого запроса; скрытая кнопка не заменяет её. ^[6]

В нашем примере сервер получает запрос на подборку, устанавливает пользователя и проверяет доступ к выбранному материалу. Только затем он выдаёт результат. Если поменять номер подборки в запросе, доступ должен снова проверяться: разрешение на один объект не означает разрешения на все объекты того же типа. ^[6]

Виды и способы запуска

Документация Telegram различает способы запуска, например кнопку профиля, кнопку в сообщении, меню бота и прямую ссылку. Это примеры, а не исчерпывающий список. Состав входных данных зависит от способа запуска; поле пользователя необязательно. ^[1]

По назначению здесь удобно выделить три учебные категории: просмотр информации, отправка заявки и покупка. Это классификация редакции для объяснения задач. Один сервис может совмещать их: сначала показать содержание подборки, затем принять запрос и предложить платный материал. Категория помогает выбрать результат проверки: открытая карточка подходит для просмотра, но ещё не означает принятой заявки или выполненной покупки.

Практика: от демонстрации к своей задаче

В международной документации платформы есть демонстрационные магазины; исторический DurgerKingBot показывал оформление вымышленного заказа. Его назначение — иллюстрировать интерфейс, а не подтверждать коммерческую эффективность мини-приложений. ^{[4] [5]}

Для российского контекста рассмотрим учебный пример: региональное издание выдаёт читателю тематическую подборку публикаций. Это вымышленная организация, не рыночный кейс. В этом примере предусмотрен вход с данными пользователя. Пользователь выбирает тему «Городская среда», нажимает кнопку и получает список материалов. Редакция заранее определяет результат: сервер сформировал нужную подборку, а интерфейс показал её этому участнику проверки.

Если издание добавит продажу цифрового сборника внутри Telegram, действует отдельная последовательность. Для цифровых товаров и услуг документация требует Telegram Stars с обозначением валюты XTR. После предварительного запроса pre_checkout_query бот одобряет или отклоняет заказ, затем ожидает successful_payment — уведомление об успешном платеже. Только после него следует выдача товара. ^[4]

В учебной проверке оплаченный, но не выданный сборник будет отдельным незавершённым случаем. Так редакция увидит, где возникла проблема: до оплаты или при предоставлении результата. Приписывать обеим ситуациям одинаковый статус «успех» было бы неверно по выбранному определению завершения.

Как проверить результат

Проверку организуем как закрытый учебный прогон из ста заранее пронумерованных сценариев. Каждый сценарий — одна попытка получить подборку; повторное нажатие в той же попытке не создаёт новую строку учёта. Это число сценариев, а не число уникальных людей. Принцип проверки разрешений и обработки отказов опирается на OWASP; конкретные входы и числа ниже заданы редакцией. ^[6]

В учебном наборе сценарии 1–20 содержат испорченные данные запуска: сервер их отклоняет. Сценарии 21–40 проходят проверку данных, но запрашивают закрытую подборку без нужного права. Сценарии 41–100 имеют корректные данные и разрешение, получают подборку и подтверждение её отображения. Получаются 80 сценариев с проверенными данными и 60 с выданным результатом.

Доля определяется как число выбранных исходов, делённое на общее число исходов рассматриваемой группы; перевод в проценты соответствует определению относительной частоты в учебнике OpenStax. ^[7]

Доля выдач среди всех сценариев:

Доля выдач среди сценариев с проверенными данными:

Числитель одинаков: 60 состоявшихся выдач. Знаменатели отвечают на разные вопросы, поэтому показатели нельзя заменять друг другом. Единица подсчёта — сценарий одного законченного прогона. Процент без указанной группы был бы неоднозначным.

Здесь отказ в первых сорока сценариях — ожидаемый безопасный результат. Если все сто сценариев завершились именно так, как задано, проверка поведения пройдена полностью, хотя доля выдач составляет лишь 60%. Эти числа не измеряют популярность сервиса, конверсию реальной аудитории или качество защиты от всех атак. При пустой группе долю не вычисляют: деление на ноль не определено.

Ошибки, ограничения и спорные вопросы

При проверке совместимости полезно записать клиент, его версию и способ запуска. isVersionAtLeast проверяет поддержку требуемой версии Bot API — программного интерфейса Telegram — в приложении пользователя. ^[1] Условия разработчика дополнительно допускают ограничения по клиентам и регионам. ^[3] Поэтому учебный прогон нужно повторять на тех конфигурациях, для которых заявлена поддержка; универсального вывода из одного успешного запуска нет.

Другая ошибка — считать знакомое оформление гарантией поставщика. Пользовательские условия возлагают работу стороннего сервиса и качество его предложения на поставщика. Перед передачей данных полезно выяснить, кто оказывает услугу и где доступны его условия. ^[2] Даже подтверждённый вход не отвечает на вопрос, надёжно ли организация исполнит обещанное.

При взаимодействии мини-приложение получает IP-адрес, то есть сетевой адрес подключения. Дополнительные базовые сведения, передаваемые Telegram, зависят от приложения и способа открытия. Пользователь также может сам передать телефон, текст или местоположение; за обработку переданного поставщику отвечает поставщик. ^[2]

Правовой аспект в России

Для обработки персональных данных применяются соответствующие основания статьи 6 части 1 закона № 152-ФЗ; согласие названо в пункте 1 и не является единственным основанием. Статья 5 части 2, 4 и 5 связывает обработку с определёнными законными целями и ограничивает избыточный сбор. Использована редакция от 26.07.2026. ^[8]

Применительно к учебному изданию это означает: открытие приложения само по себе не объясняет, зачем собирать дополнительные сведения о читателе. Цель и основание необходимо оценивать для конкретной обработки. Это правовой вывод из указанных норм, а не универсальная схема согласия. ^[8] Условия Telegram также требуют доступной политики конфиденциальности, соответствующей фактической работе приложения. ^[3] До запуска реального сервиса правовую схему должен проверить юрист.

Частые вопросы

Связанные термины