Перейти к содержанию

Печать из веб-приложения на локальный принтер

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

Рекомендуемая архитектура

Frontend передаёт своему backend-у ссылку на бизнес-документ и выбранную точку или принтер. Backend генерирует либо получает файл, вызывает CloudPrint Public API и возвращает собственный идентификатор операции. client_secret и Bearer-токен не попадают в браузер.

Выбор принтера

Во время настройки получите принтеры через GET /api/v1/printers и сохраните стабильный printer_id. В интерфейсе можно показать имя, агент и online-статус, но отображаемое имя не является ключом маршрутизации.

Интерфейс оператора

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

Работа при сетевых сбоях

Backend должен передавать стабильный Idempotency-Key, сохранять print_job_id и продолжать проверку после обновления страницы. После timeout нельзя считать запрос неуспешным — сначала повторите тот же идемпотентный вызов или восстановите сохранённый результат.

Чего избегать

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

Чек-лист перед запуском

  • Создавайте задания на backend, не полагаясь на диалог печати браузера.
  • Храните API-ключи на backend и ограничивайте их аккаунтом владельца.
  • Сохраняйте стабильный идентификатор принтера, а не только отображаемое имя.
  • Явно задайте обработку конечных статусов, повторов и защиту от двойной печати.

Следующие шаги

Руководства по интеграции CloudPrint, подключению локального агента и эксплуатации печати.