Разработка расширения для браузера: задачи, права и публикация

Расширение для браузера — небольшая программа, которая работает прямо в Chrome, Edge, Firefox или Safari: добавляет кнопку, читает нужные данные со страницы, заполняет формы или связывает сайт, который открыт у сотрудника, с вашей CRM и сервисами. Простое расширение с одним сценарием обычно собирается за одну–две недели, ещё несколько дней уходит на проверку магазинов расширений.

Какие задачи решает расширение

Расширение полезно, когда работа уже идёт в браузере, а нужного действия на сайте нет. Вместо отдельного приложения сотрудник или клиент нажимает кнопку прямо на той странице, где находится.

• Сбор данных. Карточка товара, контакт или объявление сохраняется в CRM или таблицу одной кнопкой, без копирования руками.
• Подсказки на странице. Расширение показывает рядом с полем нужный статус, цену или историю клиента из вашей системы.
• Заполнение форм. Повторяющиеся поля в кабинетах и админках заполняются из ваших данных.
• Связь с ИИ-агентом. Выделенный текст или открытая страница уходит агенту, а ответ возвращается в боковую панель — подробнее в разборе «ИИ-агент для бизнеса».
• Продукт для клиентов. Отдельное расширение как самостоятельный продукт или как спутник вашего веб-сервиса.

Если задача шире одного действия на странице, правильнее может быть веб-сервис или Telegram-бот. Это стоит обсудить на разборе задачи: иногда расширение — самый короткий путь, а иногда лишний слой.

Как устроено современное расширение

Chrome, Edge и другие браузеры на основе Chromium принимают расширения в формате Manifest V3; Firefox поддерживает тот же формат с небольшими отличиями, а для Safari расширение упаковывается в приложение через Xcode. Поэтому одна кодовая база обычно покрывает все четыре браузера, а различия закрываются небольшими настройками сборки.

• Фоновый обработчик (service worker) принимает события и ходит в ваш сервер.
• Скрипт страницы читает и меняет только то, что нужно на конкретных сайтах.
• Всплывающее окно или боковая панель — интерфейс расширения.
• Страница настроек — вход в аккаунт, выбор режима и языка.

Удалённый код в Manifest V3 запрещён: вся логика расширения проходит проверку магазина вместе с ним, а данные и правила приходят с вашего сервера.

Права и безопасность

Главный вопрос и для пользователя, и для проверки магазина — какие права просит расширение. Чем шире доступ (например, ко всем сайтам), тем строже проверка и тем осторожнее люди при установке.

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

Эти правила мы применяем и в собственных продуктах: безопасность — требование к каждой правке, а не отдельный этап перед сдачей.

Публикация в магазинах расширений

Расширение публикуется в Chrome Web Store, Microsoft Edge Add-ons, Firefox Add-ons и App Store (для Safari). Для каждого магазина нужны описание, скриншоты, иконки, политика конфиденциальности и объяснение каждого запрошенного права. Проверка обычно занимает от нескольких часов до нескольких дней, а при широких правах — дольше.

Для внутреннего инструмента компании расширение можно не публиковать открыто: оно ставится по закрытой ссылке или через управление браузерами в компании.

Сроки и стоимость

Расширение с одним сценарием — кнопка, чтение страницы и отправка в ваш сервис — обычно занимает одну–две недели работы. Связь с несколькими системами, вход по аккаунту, боковая панель с ИИ-агентом и поддержка Safari увеличивают срок. Точную оценку даём после разбора задачи — из чего она складывается, описано в разборе «Стоимость разработки ПО».

Начинать лучше с одного сценария для одного браузера, а остальные добавлять следующими релизами: так польза появляется раньше, а решения проверяются на живых пользователях. Подробнее — в разборе «Разработка MVP».

Расширение, веб-сервис или бот: что выбрать

Расширение — не единственный способ добавить нужное действие в работу. Похожие задачи решают веб-сервис и бот в мессенджере, а выбор зависит от того, где находится человек в момент, когда ему нужна помощь.

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

Этапы разработки расширения

Работа идёт короткими шагами, и после каждого есть результат, который можно проверить руками.

1. Разбор задачи. Фиксируем один главный сценарий: на каких сайтах работает расширение, что читает, куда отправляет и что видит пользователь. Здесь же решаем, какие права действительно нужны.
2. Прототип. Делаем рабочую кнопку или боковую панель на одном сайте и в одном браузере, чтобы убедиться, что данные со страницы читаются надёжно.
3. Серверная часть. Настраиваем вход по аккаунту, приём данных, проверку полей и запись в CRM, таблицы или другие системы.
4. Интерфейс и тексты. Всплывающее окно, настройки, понятные сообщения об ошибках и языки интерфейса.
5. Проверка. Тестируем на реальных страницах, в разных версиях браузера и на медленном соединении, а отдельно — поведение расширения, если сайт поменял вёрстку.
6. Публикация. Готовим описание, скриншоты, политику конфиденциальности и объяснение прав, отправляем на проверку магазина или раздаём по закрытой ссылке.

Что проверять при сдаче каждого этапа, подробно описано в разборе «Приёмка программного проекта».

Обновления после публикации

Расширение работает на чужих страницах, поэтому его жизнь зависит не только от вашего кода. Сайт, с которого расширение читает данные, может поменять вёрстку, браузер — правила для расширений, а магазин — требования к описанию и правам.

• Правила чтения страниц, например какие поля и где искать, лучше хранить на сервере как данные: если сайт поменялся, часть исправлений выкатывается без новой проверки магазина.
• Ошибки расширения стоит собирать в журнал на сервере — без личных данных, но с версией расширения и браузера и адресом страницы.
• Каждое обновление снова проходит проверку магазина, поэтому крупные изменения удобнее собирать в плановые релизы, а срочные исправления выпускать отдельно.
• Браузеры обновляются автоматически, поэтому расширение стоит проверять на новых версиях заранее, а не после жалоб пользователей.

Поддержку после запуска мы закладываем в план сразу: короткая проверка после обновлений браузеров и правки по журналу ошибок обходятся дешевле срочного ремонта.

Частые ошибки

Большинство проблем с расширениями появляется не в коде, а в решениях, принятых на старте.

• Слишком широкие права «на всякий случай». Доступ ко всем сайтам усложняет проверку магазина и отпугивает людей при установке.
• Ключи и пароли внутри расширения. Код расширения можно открыть и прочитать, поэтому всё секретное хранится только на сервере.
• Логика, завязанная на случайную вёрстку. Если расширение ищет кнопку по автоматически созданному названию класса, оно ломается при первом обновлении сайта.
• Сразу четыре браузера и десять функций. Первая версия выходит позже, а польза главного сценария так и остаётся непроверенной.
• Нет политики конфиденциальности. Без понятного описания, какие данные собираются и зачем, магазины отклоняют расширение.
• Нет плана обновлений. Расширение без поддержки перестаёт работать незаметно, и об этом узнают от пользователей.

Как мы работаем

Расширения мы делаем в рамках услуги Разработка ПО на заказ: начинаем с разбора задачи, называем срок и состав первой версии, а затем выпускаем её короткими этапами. Код, доступы к магазинам расширений и серверная часть остаются у заказчика.

Опыт, на который мы опираемся, — собственные продукты Wallet, Legal и Контент-завод: серверная часть, вход по аккаунту, ИИ-функции, публикация в магазинах приложений и поддержка после запуска. Те же правила — минимальные права, ключи только на сервере, журнал ошибок и плановые релизы — применяем и к расширениям.

Если расширение — часть большего продукта, например спутник веб-сервиса или ИИ-агента, обсуждаем всё вместе: так проще не дублировать логику и держать данные в одном месте.