Фон:
Я работаю над приложением rails, которое будет открывать статьи внутри самого приложения через iframe (с навигационной панелью вверху моего приложения, вроде StumbleUpon). Но я заметил, что некоторые веб-сайты, публикующие статьи (примеры: pitchfork.com, vox.com, theverge.com), предотвращают загрузку в iframe, задав для X-Frame-Options значение SAMEORIGIN или DENY.
Мой текущий план по обходу этой проблемы - посмотреть на заголовок ссылки и проверить его, чтобы увидеть, содержит ли он X-Frame-Options. Если это так, я откажусь от iframe и просто открою исходный сайт в новой вкладке.
Кажется, этот метод работает для некоторых веб-сайтов (например, pitchfork.com), потому что, когда я запрашиваю заголовок с pitchfork.com, я получаю следующее:
server: nginx/1.4.6 (Ubuntu)
content-type: text/html; charset=utf-8
x-frame-options: SAMEORIGIN
date: Wed, 27 Jan 2016 17:47:54 GMT
x-varnish: 912263733 912263044
age: 8
via: 1.1 varnish
connection: keep-alive
Проблема:
Для некоторых веб-сайтов (например, vox.com), когда я загружаю их в iframe, консоль разработчика Chrome сообщает мне:, что x-frame-options предотвращает загрузку сайта в iframe. Но когда я просматриваю заголовок, нигде нет x-frame-options! Все, что я получаю, это:
server: nginx/1.6.2
date: Wed, 27 Jan 2016 17:26:15 GMT
content-type: text/html
content-length: 172
connection: close
Как vox.com это делает? Для дальнейшего разъяснения я попытался использовать этот инструмент, который я нашел в другой пост stackoverflow, и он также не смог правильно определить, что vox.com блокирует фреймы с помощью x-frame-options.
1) Может ли Vox установить параметры x-frame где-нибудь, кроме заголовка? Если второе, как я могу это обнаружить?
2) Какие-либо другие альтернативные стратегии, которые вы рекомендуете для обнаружения недружелюбных к iframe сайтов, чтобы я мог вместо этого настроить их открытие в новой вкладке?
