Как сделать свой Widget-сервис: создание, интеграция и "подводные камни".


Виджеты - это различный полезный функционал для ваших пользователей, созданный сторонними сайтами, который можно размещать через небольшой исходный код на вашем сайте. Например: калькуляторы, инфо-баннеры, прогноз погоды, курсы валют мини-игры и конечно же, коды вставки роликов и рекламных баннеров. 

Сейчас всё большую популярность приобретают игровые и достаточно сложные микро-приложения, реализованные на различных технологиях HTML5: Canvas, WebGL, Audio, Video, WebRTC и т.д.

Допустим, что Вы реализовали какой-то полезный функционал на своём сайте (на своей стороне) и хотите дать возможность размещения этого функционала в виде виджета на страницах других веб-сайтов их веб-мастерами.


Как это сделать правильно и какие "подводные камни" существуют?


Есть три основные задачи:
1. Удостовериться, что домен (сайт) имеет возможность использовать виджет.
2. Удостовериться, что запрос отправлен человеком (хотя бы в большинстве случаев).
3. Максимально защитить функционал виджета от копирования и использования без нашего согласия.

Заранее, зарезервируем переменные, используемые в тексте в дальнейшем:
FRONT_WKEY - front-end ключ виджета для конкретного домена
BACK_WKEY - back-end ключ виджета для конкретного домена


1. Теперь, разделим проблему №1 ("контроля домена") на 2 варианта использования виджета:

1.1. Без бэка у владельца сайта: при получении запроса (вместе с TOKEN-ом: о нём - ниже) на загрузку виджета,  делаем обратный парсинг HTML-кода страницы сайта (где размещён виджет) с нашей стороны (со стороны бэкенда владельца функционала виджета) по параметру REFERER, и, если FRONT_WKEY (часть кода виджета) присутствует в том коде, который мы отправили владельцу сайта (при формировании кода виджета) и сформированный (клиентским JS-скриптом) TOKEN запроса для загрузки виджета (параметры: REFERER, IP, FRONT_WKEY, RANDOM, TIMESTAMP) верен - мы включаем функционал виджета.

1.2. С доступным бэком у владельца сайта: при первоначальном формировании кода при экспорте кода виджета, мы генерируем серверный код (на выбранном языке) для его последующего размещения на бэкенде владельцем сайта (где будет размещаться виджет), который сможет формировать TOKEN через AJAX-запрос к этому скрипту на основании параметров: REFERER, IP, BACK_WKEY, RANDOM, TIMESTAMP.
Разница от предыдущего в том, что вся вычислительная часть (часть, формирующая TOKEN по формуле) теперь находится на стороне сервера и пользователь не может получить BACK_WKEY в открытом виде. Поэтому, он не может подделать запрос, а нам не нужно проверять, что виджет реально находится на странице (в отличие от первого способа, где всё формируется с клиентской стороны JS-скриптом).
При загрузке страницы, в этом случае,  мы уже не делаем обратный парсинг, а сразу проверяем сформированный TOKEN при запросе функционала виджета.

Итог: 
1.front: front-token(js)+callback parsing HTML
2.back: back-token (without any parsing)


2. Теперь, рассмотрим возможные решения проблемы №2: контроль живого человека:
1. Авторизация пользователя на стороне владельца виджет-сервиса
2. Авторизация пользователя на стороне владельца сайта
3. Авторизация через соц.сети: OpenID
4. Создание функционала капчи (CAPTCHA) внутри виджета для защиты от роботов
5. Контроль JS-событий интерфейса и возможностей браузера виджетом


3. Защита кода виджета:
1. JS-обфускация клиентского JS-кода.
2. Весь важный функционал реализуем на серверной стороне.
3. Каждый запрос контента - подписывается токеном, который ограничен по времени до минимального таймаута. Например: обмен через JSON + ограничение в 5 секунд.



Подписка на новости:

Самые полезные и признанные экспертами публикации в сферах IT-бизнеса и Web-разработки:

Сертификат

Certificate for nickname xmoonlight, is registered to: https://sitecoder.blogspot.com