Похоже, что единственный способ защитить наш контент - это проверить, соответствует ли URL страницы, на которой размещен наш javascript, сайту подписки.
Ах, но в коде на стороне клиента или на стороне сервера?
У них обоих есть свои недостатки. Делать это с серверным кодом ненадежно, потому что некоторые браузеры вообще не будут передавать заголовок Referer, и если вы хотите остановить кэши, сохраняющие копию скрипта, не позволяя выполнить проверку Referer, у вас есть обслуживать с заголовками nocache или Vary: Referer, что может повлиять на производительность.
С другой стороны, с проверками на стороне клиента в возвращаемом вами сценарии вы не можете быть уверены, что среда, в которой вы работаете, не была саботирована. Например, если ваш тег сценария включения был похож на:
<script src="http://include.example.com/includescript?myid=123"></script>
и ваш серверный скрипт посмотрел 123 как идентификатор клиента, использующего домен customersite.foo, он может ответить сценарием:
if (location.host.slice(-16)==='customersite.foo') {
// main body of script
} else {
alert('Sorry, this site is not licensed to include content from example.com');
}
Что кажется достаточно простым, за исключением того, что включающий сайт мог бы заменить String.prototype.slice функцией, которая всегда возвращала customersite.foo. Также могут быть подозрительными различные другие функции, используемые в теле скрипта.
Включение <script> из другого контекста безопасности сокращает оба пути: включающий сайт должен доверять исходному сайту, чтобы он не делал ничего плохого в контексте безопасности, например, крал пароли конечного пользователя или заменял страницу большим козлом ; но в равной степени код исходного сайта является только гостем в потенциально злонамеренно настроенном контексте безопасности включающего сайта. Таким образом, мера доверия должна существовать между двумя сторонами, где один сайт включает сценарий от другого; проверка домена никогда не будет 100% надежным механизмом защиты.
Я хотел бы также включить таблицу стилей, если это возможно, для стилизации элемента, но я не уверен, что смогу загрузить это вместе с javascript.
Вы, конечно, можете добавить элементы таблицы стилей к элементу заголовка документа, но вам потребуется некоторое строгое пространство имен, чтобы оно не мешало другим стилям страницы. Вы можете предпочесть использовать встроенные стили для простоты и во избежание помех специфичности из основной таблицы стилей страницы.
На самом деле это зависит от того, хотите ли вы, чтобы ваш сгенерированный контент был частью главной страницы (в этом случае вы могли бы предпочесть, чтобы включающий сайт сам решал, какие стили они хотели для него), или вы хотите, чтобы он был изолирован не зависит от контекста (в этом случае вам, вероятно, будет лучше поместить ваш контент в <iframe> со своими собственными стилями).
Я думаю об использовании jquery, поэтому включаемый файл сначала будет вызываться в jquery
Я бы постарался не втягивать jQuery на страницу хоста. Даже с noconflict есть способы, которые могут конфликтовать с другими сценариями, которые не ожидают его присутствия, особенно с такими сложными сценариями, как другие фреймворки. Запуск двух фреймворков на одной странице - рецепт для странных ошибок.
(Если вы взяли маршрут <iframe>, с другой стороны, вы получите свой собственный сценарий для игры, так что это не будет проблемой.)