Похоже, что единственный способ защитить наш контент - это проверить, что 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>, у вас будет собственный контекст сценария, с которым можно поиграть, так что проблем там не возникнет.)
person
bobince
schedule
16.02.2010
