Какие проблемы прямой вставки кода виджета в код стороннего сайта?

Question

[Николай]

Привет, сообщество!

Недавно я пришел в команду, где работают над проектом, идея которого
заключается в том, что пользователи могут создать форму на нашей платформе, а затем могут вставить ее на свой сайт (отправка данных из формы идет также в наш проект и нашу БД). Фактически, это виджет. В общем, это клон: jotform.com только со своим блэкджэком.

Собственно, проблема вот в чем. Текущая реализация виджета формы сделана на Vue и так, что интеграция идет прямиком в код внешнего сайта. Т.е. наш DOM и JS прямиков в DOM сайта.

И зашел у нас с тимлидом спор. Тимлид говорит, что фишка проекта - это вставка прямиком в код и возможность владельцев сайта влиять на код формы (типа CSS применить). А JS легко через namespace изолировать.

Мое мнение, что такой способ интеграции это просто дичь. И так делать нельзя. Нужно использовать iframe или веб-компонент. А для влияния на CSS просто разрешить указывать свой CSS через поле в настройке формы.

Уважаемые знатоки, пожалуйста, выскажите свое мнение о подходах. Какие могут быть проблемы при прямой вставке в код неизвестного сайта? Действительно ли легко в данном случае изолировать JS и проблемы останутся только с влиянием CSS/HTML?

P.S. Если есть ссылки на интересные материалы по теме, особенно на английском, буду премного благодарен.

Answer 1

[Николай]

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

Итак, ситуация. Вам необходимо сделать возможность вставки своих виджетов в код сторонних сайтов. Для реализации этого сторонний сайт вставляет в свой код ваш JS-код. Далее ваш JS код вставляет виджет. Виджет можно вставить либо прямо в код страницы (далее прямая вставка в DOM) либо создать Iframe. Рассмотрим потенциальные проблемы обоих подходов.

JS конфликты
Прямая вставка в DOM
Здесь не должно быть конфликтов, когда используется “пространство имен”. Но при использовании сторонних библиотек, некоторые из них могут обращаться напрямую к window и это невозможно контролировать. Я столкнулся с проблемой когда vuetify обращается к window.$vue из своего кода и просто падает.

Iframe
Полная инкапсуляция, конфликты исключены

CSS конфликты
Прямая вставка в DOM
Потенциально очень серьёзные конфликты. Код внешнего сайта влияет на виджет, код виджета влияет на внешний сайт. Ваш виджет ломает внешний сайт, внешний сайт ломает ваш виджет.

Iframe
Полная инкапсуляция, конфликты исключены

Cookies (описанное ниже так же относится и к localStorage)
Если необходимо отправлять ваши кукисы из виджета

Прямая вставка в DOM
Мы не можем отправлять кукисы третьей-стороны из JS. Если использовать для отправки кукиса заголовки с сервера во время загрузки статики или скрытый iframe, то браузер будет опознавать их как кукисы третьей стороны. По современным оценкам кукисы третьей стороны отключены у 25-50% пользователей. И тренд такой, что это число будет только расти.

Iframe
Мы можем устанавливать свои кукисы, как кукисы первой стороны. Возможно, для некоторых браузеров, потребуется выполнить POST запрос для одобрения установки кукисов.

Безопасность
Прямая вставка в DOM
Если ваш виджет должен общаться с вашим сервером, то прямая вставка - это полный провал в безопасности. Для возможности выполнения запросов вам необходимо будет включить CORS (отключить same-origin policy). Это приведет к тому, что уязвимость, позволяющая исполнять код на внешнем сайте, позволит злоумышленнику отправлять запросы на ваш сервер от чужого имени, при стечении обстоятельств.

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

Iframe
Продолжаем использовать same-origin policy. Данные виджета изолированы.

Заключение: единственный адекватный вариант - вставка через iframe.

P.S. Тимлида я обыграл. Но меня поражает: как люди с такими познаниями становятся тимлидами с зп >700к (это не Россия, но все равно дофига)?!

Answer 2

[Николай Шабалин]

А в чем проблема изолирования JS?

В es5 функциональная область видимости. В es6 блочная. Этих знаний достаточно, чтобы сделать железобетонный JS. Ну и используйте переменные с блочной областью видимости - let, const.

(function(d, w){
//ваш код
})(document, window)

и всё ваш код изолирован.

По-поводу HTML тоже проблем нет, а вот с CSS вы хапанёте очень сильно. Нужно будет скидывать стили для всех сайтов. CSS раздуется до неимоверных размеров.

input {
  background-color: transparent !important;
  border: 1px solid #0de !important;
  ...
}

Если же Вы наоткуп отдаете стили, чтобы интеграторы с этим вопросом справлялись сами, то кажется, что им это не нужно. Ведь это нужно иметь штатного верстальщика и не всем он нужен. Хочется просто подключить JS и чтобы работало.

В общем, сам я больше за iframe только из-за того, что отгребу от CSS.

Comments

[Николай]

Николай, спасибо за глубокой ответ. Насчет JS. Я не сильный JS программист (занимаюсь другой областью), знаю об указанных вами способах. Согласен, что в JS проблем должно быть меньше. Но я не уверен, что совсем не будет. Я немного поиграл с существующем кодом (а он написан на Vue + Vuetify), попробовал вставить его в сайт с Vue. И получил конфликт именно от Vuetify. Я не копал далеко, возможно надо лучше изолировать, возможно Vuetify как-то хитро обращается, т.к. он выдает такую ошибку: [Vuetify] Multiple instances of Vue detected (при этом вариант без Vuetify конфликтов не дал). Я просто не уверен, что изолирование может быть панацеей в JS. Если я правильно понимаю, в конечном итоге, через windows это все можно вытащить. Или я не прав?

Я тоже склонен к iframe, даже скорее к вебкомпоненту. Просто, даже такие вещи, как input range являются shadow DOM, а не прямой вставкой. Поэтому, прямая вставка меня очень настораживает. CSS, как вы верно отметили - 100% батхерт!

[Николай Шабалин]

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

С вебкомпонентами тоже не всё так просто. Смотря какая у Вас поддержка браузеров. Может получится так, что браузер пользователя не сможет в них.

[Николай]

Николай Шабалин, с polyfill должно быть достаточно.

Answer 3

[d'Ivan]

iframe нужно использовать для вставки кода стороннего сайта, как минимум, по причине безопасности пользователей своего сайта. Если что-то сломается или будут проблемы безопасности во вставке кода, то это не коснется твоего сайта.

Answer 4

[Павел Корнилов]

ИМХО, тимлид прав, проблем никаких не должно быть, в случае строгой инкапсулляции всего JS-кода. Если нужно взаимодействие с внешним кодом - можно предоставить единую переменную для реализации какого-то клиентского API.

Проблемы могут быть при обработке входящих данных с неизвестных сайтов на сервере. Вот там нужно будет жёстко всё фильтровать.

Comments

[Николай]

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

За JS я особо не переживаю. Просто я не сильный JS программист (занимаюсь другой областью), поэтому уточнил о нэймспэсах, учитывая, что это Vue и браузер, со своим windows объектом. Но вот как можно в этой ситуации разрулить CSS, при этом ни разу не поимев проблем, я даже не представляю.

[Павел Корнилов]

Николай,
1. Согласен, действительно, данные могут приходить на сайт откуда угодно
2. Разруливай, используя наследственные записи CSS. У них и более высокий приоритет, и меньше шансов, что они сломают что-то в сайте

#parent #app_body ul {
/* ... */
}

[Павел Корнилов]

Имхо, для п.2 хорошо бы подошёл LESS, как компиллируемая разметка с обоих сторон - и фронт, и бэк.
Но это уже тонкости.

[Николай]

Павел Корнилов, как разруливать, если во внешнем сайте будет безумие типа:

div > div {
   display: flex !important
}

Да там может, что угодно быть. Это же абстрактный водрдпресс-сайт в вакууме :) . Получается, что каждый наш DOM элемент надо охватить CSS свойствами с !important (гарантировать сброс до нужных нам). При этом, изменить эти свойства из вне уже не получится. Ведь так?

[Павел Корнилов]

Николай, использование !important - всегда считалось плохой практикой. В данной ситуации это можно отнести к ошибкам целевого сайта, на которые внешний модуль повлиять не может.
Такие ошибки могут быть и в вёрстке, и в скриптах. C'est La Vie.

[Николай]

Павел Корнилов, так использовать id в css #parent #app_body тоже плохая практика. Но если делать виджет, то надо ведь понимать и принимать, что во внешних сайтах будет плохой код.

В любом случае, большое спасибо за ваш отклик. Он очень полезен для меня и помогает сформулировать проблемы и подходы.

[Павел Корнилов]

Николай, использовать наследственные селекторы - единственный простой путь инкапсуллировать CSS приложения от CSS сайта, ИМХО, какой бы практикой это не являлось. Это однозначно лучше Iimportant.

На здоровье, рад был помочь. Думаю, наша дискуссия, объясняющая многие вопросы, может быть отмечена решением вопроса, пусть даже не полным. Но этот вопрос, мне кажется, не имеет полностью однозначного решения, нужно будет искать компромиссы, исходя из обсуждаемых вариантов.

[Николай]

Павел Корнилов, не могу признать ваш ответ решением вопроса. Я не увидел в ваших ответах реального решения проблемы. К сожалению, вы не ответили как разрулить ситуацию, а просто указали что во внешнем сайте (который не контролируется обсуждаемым сервисом) используется плохая практика (для заметки, приведенное в ситуации CSS правило и без !important все cломает, если мы его не переопределим).

Я придерживаюсь мнения, что использование в данной задаче веб компонентов с их Shadow DOM позволяет решить все проблемы. Можно использовать и iframe, с дополнительными плюшками, позволяющими загрузить в него стили из внешнего сайта.

Но, как уже отметил ранее, я признателен вам за участие в дискуссии.

[Павел Корнилов]

Николай, я понял.
Как ещё один вариант напоследок - мог бы предложить делать полный сброс стилей внутри своего узла. Можно жёсткий, через те же !important
Типа (LESS):

#parent {
* {
margin: 0 !important;
padding: 0 !important;
...
}
}

[Николай]

Павел Корнилов, для сброса стилей есть all :) Я думаю, что вы не до конца поняли вопрос. Если мы сбросим стили внутри виджета через !important, то мы уже не сможем изменить их из внешнего сайта.

[Павел Корнилов]

Николай, да, со стилями беда какая-то получается.
Значит, iframe, я уже другого пути не вижу.