Електронний підпис на сайті: де ламається і у що обходиться
Електронний підпис на сайті ламається не в момент відображення штриха, а на стику трьох шарів: полотно в браузері, координатна сітка документа та криптографічна валідність.
Клієнт ставить підпис на планшеті, бачить рівний розчерк — а у збереженому файлі штрих зміщений на десятки точок або обрізаний по краю.
Причина майже завжди одна: координати полотна беруться з CSS-розмірів, тоді як внутрішня сітка відображення має іншу роздільну здатність, і при масштабуванні сторінки або зміні орієнтації пристрою точки з'їжджають.
Другий клас збоїв — втрата штрихів. Швидкий жест, палець вийшов за межу області, подію відпускання не спіймано — і на сервер іде порожній або частково порожній набір точок. Підпис формально є, але при спробі довести її походження вона не відтворюється.
Окрема історія — невалідність підписаного документа: якщо між підписанням і збереженням документ перезбирається, змінюються метадані або порядок байтів, перевірка підпису падає, хоча візуально все на місці.
Ціна таких збоїв не в коді, а в розглядах. Спір з клієнтом, де підпис нечитабельний або не підтверджується, майже завжди вирішується не на користь сервісу: довести, що розчерк справжній, а збій технічний, заднім числом неможливо.
Тому надійний електронний підпис на сайті будується навколо трьох речей: нормалізованих координат полотна, повного журналу подій підписання та перевірки валідності одразу на стороні сервера, до запису в сховище.
Розбираємо, як це закривається: від прив'язки штриха до сітки документа до сценаріїв, де підпис залишається юридично значущим після повторного збирання файлу.
Що дає коректна реалізація підпису: ефект у цифрах
Коректна реалізація підпису — це не «поле для малювання», а керований процес: захоплення штриха, прив'язка до документа, перевірка цілісності та зберігання доказу. Коли ці частини зібрані в один контур, ефект видно у вимірюваних величинах, а не у відчуттях.
Швидкість і завершеність підписання
Підписання однієї форми скорочується з хвилин до десятків секунд: клієнт не друкує дані, не сканує і не надсилає файл назад. Форма перестає «розсипатися» на етапі підтвердження — частка незавершених відправлень падає, бо підпис ставиться в тому самому вікні, де заповнені поля. Конверсія форми зростає без змін в оффері: прибирається єдиний крок, на якому люди йшли.
Цілісність даних і клас відмов
Окремий виграш — зникає клас відмов, пов'язаних із втратою даних: обрив зв'язку, закрита вкладка, повторне завантаження сторінки більше не обнуляють підпис. Чернетка і сам штрих зберігаються, при поверненні клієнт продовжує з того самого місця.
Підпис криптографічно прив'язується до версії документа — підміна вмісту після підписання стає видимою, а не гіпотетичною.
Повторні звернення та розбір
Кожна дія залишає слід: хто, коли, з якого пристрою і до якої версії документа поставив підпис. Спірні ситуації розбираються за журналом, а не за листуванням, тому повторні звернення щодо одного й того самого документа знижуються.
Для юридично значущих сценаріїв контур будується на КриптоПро — посилений підпис перевіряється на стороні отримувача, а не лише в нас.
Підсумок: час підписання — секунди, незавершені форми — рідше, втрати даних — виключені, історія дій — відновлювана.
Способи реалізації підпису: порівняння підходів
Вибір реалізації — це не про «яка бібліотека красивіше малює», а про те, де живе підпис, як він перевіряється і що залишиться в архіві через кілька років. Нижче — три реально конкуруючі підходи, між якими обирають на старті проєкту.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Нативний холст (canvas + Pointer Events) | Потрібен повний контроль над поведінкою: тиск пера, згладжування, власні жести скасування та очищення | Усе пишеться вручну: масштабування під екрани, ретина, тач і стилус, доступність. Більше коду — більше місць для помилок |
| Стороння бібліотека підпису | Потрібен робочий результат швидко, з готовими жестами, скасуванням і експортом у вектор | Залежність від чужого релізу, зайва вага на сторінці, обмежений доступ до внутрішньої геометрії штриха |
| Гібридна схема | Підпис малюється на холсті, а юридично значуща частина йде на серверний сервіс | Складніше в супроводі: два контури, синхронізація, окремі вимоги до зберігання |
Межі між варіантами розмиваються, коли підпис потрібен не як картинка, а як доказ. Якщо штрих залишається тільки в браузері, його легко підмінити в консолі — отже, потрібен серверний контур, який фіксує факт підписання, час і вміст документа.
Гібрид виправданий там, де підпис має наслідки: договори, акти, згоди. Нативний холст — де важлива швидкість і власна логіка інтерфейсу. Бібліотека — де підпис декоративний або внутрішній і час до запуску важливіший за глибину контролю.
Практичний критерій вибору: дайте відповідь, що саме ви зберігаєте — картинку штриха чи доказ. Від цього залежить і обсяг робіт, і те, які перевірки доведеться закладати одразу, а не переробляти після першого спірного документа.
Етапи впровадження електронного підпису на сайті
Впровадження підпису — це не «прикрутити поле до форми», а змінити спосіб підтвердження згоди та зберігання юридично значущого артефакту.
Нижче — як ми ведемо таку роботу, щоб на виході залишилася відтворювана схема, а не набір скриптів, які через місяць ніхто не зможе підтримувати.
- Аудит поточної форми. Дивимося, як зараз збирається згода: які поля обов'язкові, де валідується введення, що йде на сервер і в якому вигляді зберігається. Фіксуємо точки, куди вбудовується підпис, і перевіряємо, що її додавання не ламає наявний сценарій надсилання.
- Проєктування схеми підпису. Визначаємо, що саме підписується — згода, заявка, договір, — і як підпис пов'язується з документом. Проєктуємо формат зберігання: зображення штриха, прив'язка до версії документа, позначка часу та ідентифікатор клієнта.
- Налаштування захоплення. Реалізуємо область підпису з коректною обробкою введення: згладжування ліній, урахування масштабу екрана, скасування та очищення штриха. Окремо закриваємо випадок, коли підпис ставиться пальцем або стилусом, а не мишею.
- Перевірка на пристроях. Проганяємо сценарій на десктопі, планшеті та смартфоні в різних браузерах: перевіряємо, що штрих не зміщується при повороті екрана і не втрачається при повторному відкритті форми. Дивимося поведінку при повільному з'єднанні.
- Обробка та зберігання. Підпис іде на сервер разом із документом, зберігається в незмінному вигляді та пов'язується із записом про згоду. Налаштовуємо, щоб артефакт не можна було підмінити після надсилання.
- Тестування та приймання. Перевіряємо повний шлях: заповнення, підпис, надсилання, повторне відкриття, вивантаження. Окремо — сценарії збою, щоб клієнт бачив зрозуміле повідомлення, а не порожній екран.
- Передача документації. Віддаємо схему зберігання, опис точок інтеграції та інструкцію із супроводу, щоб доопрацювання не вимагали розбирати код заново.
Такий порядок знімає головний ризик — підпис, який виглядає робочим, але не пов'язаний із документом і не переживає перевірку. Опишіть вашу форму та вимоги до згоди — повернемося з оцінкою та планом робіт.
Артефакти та конфігурації, які ви отримуєте
Передаємо не «працюючий модуль», а комплект, за яким підпис можна експлуатувати, перевіряти та передати іншій команді. Нижче — що саме залишається у вас після впровадження електронного підпису на сайті.
- Конфігурація захоплення — профілі для миші, пера та пальця: згладжування, поріг початку штриха, частота опитування, поведінка при втраті фокуса та виході курсора за межі області. Окремо описано, як змінюється крива при стисненні на стороні клієнта.
- Схема координат — приведення точок до системи координат документа з урахуванням масштабу, прокрутки та повороту екрана. Без цього підпис «з'їжджає» на мобільних і при друці, а її юридична цінність падає.
- Політики доступу до даних підпису — хто і на якій підставі читає біометричний шаблон, де він зберігається, як пов'язаний з документом і як видаляється після закінчення терміну. Ролі, журнал звернень, розділення прав на перегляд і вивантаження.
- Регламент перевірки — порядок звірки підпису з еталоном, пороги збігу, що вважається збігом, що — сумнівом, а що — відмовою. Сценарії для спірних випадків і правила ескалації.
- Інструкції для користувачів і підтримки — як підписати з телефону, що робити при обриві зв'язку, як оспорити відхилений підпис. Окрема версія для першої лінії.
- Схема інтеграції — точки підключення до вашого сховища документів, системи погодження та облікових записів, формати обміну та поведінка при недоступності зовнішнього сервісу.
- Набір тестових сценаріїв — еталонні підписи, пограничні випадки та перевірки на підробку, за якими команда приймає результат і повторює його при оновленнях.
Комплект самодостатній: новий інженер розгортає підпис за ним без усних пояснень, а служба підтримки відповідає на звернення, не піднімаючи розробників. Опишіть задачу — повернемося з оцінкою та планом за вашим сценарієм підписання.
Кейс: як ми усунули втрату штрихів під час підписання
Клієнт — сервіс доставки — приймав підтвердження замовлень через екран підпису на планшеті кур'єра. На частині пристроїв лінія «рвалася»: клієнт вів палець, а на екрані залишалися окремі фрагменти. Підпис виглядав недостовірно, і його доводилося переоформлювати на папері.
Ми розібрали скарги й побачили закономірність: збої виникали на пристроях із високою частотою опитування сенсора, коли обробник не встигав за потоком подій і втрачав проміжні точки.
Проблема накопичувалася непомітно — до певного темпу руху пера все працювало, далі штрих розсипався.
Що змінили
Перевели відрисовку на буферизацію подій: точки накопичуються в черзі та згладжуються перед виведенням на полотно, а не малюються по одній у момент надходження. Додали інтерполяцію між сусідніми точками — лінія залишається неперервною навіть за швидкого руху.
Окремо синхронізували масштаб полотна та координатну сітку пристрою, через яку штрих зміщувався відносно пера.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Частка підписів із розривами | 18% | менше 1% |
| Повторні звернення щодо підпису | 6-8 на тиждень | поодинокі |
| Частка підписів, переоформлених на папері | 22% | 2% |
Рішення побудували на Signature Pad — відкритій бібліотеці відрисовки підпису, доопрацювавши її під наші умови. Стабільна відрисовка зняла основну причину повторних звернень: клієнти перестали перепитувати, чи чинний їхній підпис, а підтримка — розбирати однотипні тікети.
Чим відрізняється електронний підпис від простого зображення?
Зображення підпису — це просто набір пікселів, який браузер відмалював на полотні та зберіг як картинку. Його можна скопіювати, вставити в інший документ, відредагувати в графічному редакторі — система не відрізнить оригінал від підробки, бо немає з чим порівнювати.
Такий візуальний відбиток годиться там, де підпис підтверджує намір, а не створює зобов'язання: згода з умовами заявки, відмітка про отримання, внутрішній чек-лист. Ціна помилки тут низька, тому достатньо зафіксувати сам факт дії.
Юридично значущий підпис влаштований інакше. Він прив'язаний до конкретного документа та моменту часу: під час підписання обчислюється контрольна сума вмісту, до неї додаються дані про підписувача та позначку часу, і все це скріплюється криптографією.
Змінити після цього хоча б символ у тексті — і перевірка покаже розбіжність, підпис стане недійсним. Візуальний відбиток у такій схемі вторинний: він потрібен для читабельності, а не для доказу.
Звідси й різниця у вимогах. Для простого варіанта достатньо полотна, збереження картинки та прив'язки до сесії користувача.
Для значущого — потрібні ідентифікація підписувача, захищене зберігання ключів, журнал усіх операцій і валідація підпису під час кожного відкриття документа.
Перевірка має працювати автономно: навіть через роки сторона зможе переконатися, що документ не змінювався після підписання.
Вибір диктує не зручність інтерфейсу, а наслідки спору. Якщо підпис колись доведеться пред'явити як доказ — потрібні валідація та незмінний слід. Якщо він лише фіксує дію всередині процесу — достатньо візуального відбитка, і городити криптографію немає сенсу.
Часті технічні сумніви при впровадженні підпису
Перед стартом замовники зазвичай ставлять одні й ті самі запитання: чи спрацює підпис на планшетах і старих браузерах, чи не впаде сервер від потоку підписів, і що відбувається з даними між пристроєм і сховищем. Нижче — короткі відповіді на кожне.
Підпис працюватиме на будь-якому пристрої клієнта?
Малювання відбувається на боці браузера через стандартний canvas, тому підпис ставиться мишею, пальцем або стилусом однаково — на планшеті, ноутбуці, терміналі в офісі.
Ми перевіряємо сценарій на актуальних версіях основних браузерів і на мобільних, включно з режимом зниженої чутливості для стилуса. Якщо в частини партнерів старі пристрої — заздалегідь фіксуємо список підтримуваних і залишаємо резервний шлях через завантаження скану.
Чи не зросте навантаження на сервер?
Сам малюнок — це компактний набір координат, а не зображення, тому вага одного підпису вимірюється кілобайтами. Сервер не малює і не рендерить — він приймає готовий набір точок, валідує і зберігає.
Навіть при піковому записі десятків підписів за хвилину навантаження залишається в межах звичайного профілю API, а зберігання відбувається в об'єктному сховищі, а не в основній базі.
Як захищена передача даних підпису?
Канал закритий шифруванням, запити підписані й прив'язані до сесії користувача — підробити чужий підпис ззовні неможливо. Разом із малюнком зберігаємо мітку часу, ідентифікатор документа і версію шаблону, щоб підпис можна було однозначно зіставити з конкретною заявкою. Доступ до перегляду та вивантаження обмежений ролями, а всі операції потрапляють до журналу.
Що з відкатом і юридичною силою?
Кожна дія версіонується: якщо клієнт оспорить підпис, ми піднімаємо вихідний набір точок, мітку часу і контекст підписання. Це дозволяє довести, що документ не змінювався після підпису.
Якщо за процесом потрібен посилений підпис — інтегруємо зовнішнього провайдера, а базовий сценарій залишається як швидкий шлях.
Опишіть свій сценарій — повернемося з оцінкою та планом щодо сумісності, навантаження і захисту даних.
Обговоримо ваше завдання щодо впровадження підпису
Щоб повернутися з оцінкою та планом впровадження, а не із загальними словами, нам потрібно зрозуміти вашу поточну форму: де вона живе, як підписувач потрапляє на неї і що відбувається з підписаним файлом далі.
Опишіть це у вільній формі — далі ми поставимо уточнювальні запитання й покажемо, як електронний підпис на сайті ляже на ваш процес.
Як зазвичай відбувається обговорення задачі:
- Розбираємо поточну форму: які поля заповнює клієнт, на якому кроці ставиться підпис, хто і як перевіряє результат.
- Уточнюємо вимоги до юридичної значущості: потрібен простий чи посилений підпис, чи потрібна прив'язка до особи через підтверджений контакт.
- Дивимося, куди йде підписаний документ: пошта, CRM, файлове сховище або зовнішній сервіс — від цього залежить формат вивантаження.
- Перевіряємо сценарії відмови: обрив зв'язку в момент підписання, повторне надсилання, відмова клієнта, оспорювання підпису.
- Збираємо оцінку робіт за етапами — верстка та логіка форми, серверна частина, зберігання й перевірка підписів, інтеграції.
- Повертаємося з планом впровадження: послідовність кроків, що потрібно з вашого боку, де точки зворотного зв'язку по ходу робіт.
- Узгоджуємо порядок приймання: на яких даних перевіряємо, які сценарії вважаємо закритими.
Зворотний зв'язок на кожному етапі — не формальність: ви бачите проміжний результат на тестовому стенді й можете скоригувати логіку до того, як вона піде в продакшн. Так ми знімаємо ризик, що готова форма не збіжиться з тим, як реально працює ваш відділ.
Опишіть задачу у зручному вигляді — посиланням на поточну форму, скриншотами або коротким текстом. Повернемося з оцінкою та планом робіт, без зобов'язань з вашого боку.
