Как стать автором
Обновить

Комментарии 35

Для более распространенных случаев, например, размещения приложений и виджетов на сторонних сайтах, хочется порекомендовать Cross-window messaging.

Не требует костылей в виде скрытого сервер-серверного общения. Не требует больших костылей, называемых проксированием. Поддержка отличная.
дак мы это и используем
 window.parent.postMessage( curXpath, "*");

вопрос в том что кто-то должен принять ваше сообщение на строннем сайте.
В нашем случае вмя история с прокси нужна для того чтобы как раз внедрить в чужой html наш JS который будет слать postMessage
Конечно, всё именно так. Потому я и оговорился про более распространенные случаи — где содержимое ифрейма поддается контролю, и его владелец может самостоятельно внедрить в него источник сообщения.
это да, в идеале так и должно быть )
Небольшое замечание, может быть, полезное. Наличие/отсутствие base при генерации абсолютных адресов учитывается?
у нас там все по простому, без base. На самом деле сейчас использовать относительные урлы не модно, и часто приходится смотреть в код всяких сайтов — относительных почти нигде уже нет
Круто! буквально вчера делал подобную вещицу. Только задача была несколько иная сделать визуальный редактор для HTML страничек. Есть HTML код, отдельно файлы стилей и скриптов. Ситли и скрипты инжектятся в хтмл + добавляется скрипт по выделению елментов и обмену сообщений все это добро пишется в iframe. У себя по HTML строим еще одну DOM. По клику из ифрейма летит через postMessage css селектором. По селектору находим елемент в DOM делаем изменеия и отсылаем обратно через postMessage в iframe. В iframe визуально отображаем изменеия. По окончании редактирования DOM сохраняем в стрингу и отправляем на сервак — все рады.
да, неплохая схема. Только не очень понял зачем в родителе держать dom клон того что в iframe (если я правильно понял). Еще вариант целиком редактор страницы заембедить в редактируемую страницу (это к комменту выше)
В ифрейме отрендеренный дом со скриптами, стилями и картинками например

real jquery code

А который мы правим и сохраняйм потом в строку имеет метки куда вставлять скрипты картинки и т.д.

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

Таким образом или имеем копию или делаем обратное преобразовние, что мне показалось, затратнее.

Iframe
[script]real jquery code[/script]
[img src=«our-cdn/image100500.jpg» /]

DOM
[script src=«jquery.2.0.0.js»][/script]
[img src=«image100500.jpg» /]

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

Через nginx можно сделать просто и топорно.
(целевой хост задаёте как ?host=wikipedia.org, всё остальное идентично таргету).
HTTPSecureLink будет работать, решение вполне рабочее.
Однако, тяжело сделать плюшки типа замены URL на серверсайде, но вполне можно на клиенте (это, конечно, не самый быстрый процесс).

server {
    listen       8081;
    server_name  proxy.qwerty;
    resolver 8.8.8.8;
error_log /var/log/nginx/debug.log debug;
    location / {
        #allow 1.2.1.1;deny all;
        set $newproto "http";
        if ($arg_secure = "Y"){ set $newproto "https";}
        set $newhost $arg_host;
        if ($newhost !~* ^(.+)$ )  {return 406;}

        proxy_pass $newproto://$newhost:80$request_uri;
    }
}


В любом случае спасибо за подробный пост и ценное напоминание про безопасность.
А что будет, если через этот прокси попробовать загрузить его самого (http://highlighter.indexisto.com/?md5=6ec7rdHxUfRkrFy55jrJQA==&url=http%3A%2F%2Fhabrahabr.ru&expires=1390468360)?
Сложно заменить урлы на сервер-сайде? Да одна строчка :)
sub_filter 'google.ru' 'zn.sergeybelove.ru';
sub_filter_once off;

Demo: zn.sergeybelove.ru
На момент написания конфига sub_filter не поддерживал переменные в аргументах.
То, что написали вы работает только для конкретного домена. Плюс. Вы не думаете, что это может заменить не только ссылки?
я на самом деле в nginx не супер силен, финальный аккорд настраивали наши администраторы.
Я не уловил идеи, что этот конфиг делает?
Смотрите, всё очень просто.

Допустим вам нужно отпроксировать test.ru/page/?param=1&val=2

Это превращается в

proxy.qwertypage/?param=1&val=2&host=test.ru
Теперь настраиваем модуль nginx HttpSecureLinkModule.
Мы думали, что пугающей красной надписи в начале страницы достаточно:
WARNING: this article is obsoleted. Please refer to nginx.org/en/docs/ for the latest official documentation.

Но оказывается нет. И для кого тратим силы на поддержку русской версии документации? Видимо она никому не нужна.
Если набирать название модуля не так, как его назвал Игорь Сысоев, а так, как его обозвал Cliff Wells (автор wiki.nginx.org), то результат будет предсказуем.

www.google.ru/search?q=ngx_http_secure_link_module
Молодцы. Жаль, что Яндекс не реализовал подобную идею в Веб-Визоре.
Хм. А что по вашему Яндекс реализовал в Вебвизоре? В вебвизоре, например, есть режим, в котором проигрываемая страница грузится прямо с сайта, без всяких прокси.
Да, и правда, моя ошибка. Просто, псоле возникновения ошибки обратился к справке, в ней они предлагают попросить администора сайта убрать «Same Origin» :) А оказалось, что есть опция кэширования (правда с ограничением в 200 Кб).
Да, если страница не даёт загрузить себя в ифрейм, то воспроизвести на ней ничего не получится.
Вебвизору/аналитике проще, потому что на сайте УЖЕ установлен JS с домена яндекса. Так что им достаточно в URL передать зашифрованную команду «запусти виджеты аналитики/вебвизора» и всё — проксирование в общем-то и не нужно становится.
Согласен, проще. Но, 1) в урле нельзя ничего передавать, некоторые сайты от этого ломаются, 2) показывать интерфейс внутри чужой страницы плохо, поэтому проксирование всё-таки нужно.
В этот раз код для критики не выкладываете? :) Тогда покритикую практику финализации всего и вся — она не дает никаких преимуществ, но усложняет чтение и без того многословного ява кода. В самом деле, какого размера у вас методы, что вы боитесь случайно изменить локальную переменную или аргумент? Я называю этот антипаттерн «финал головного мозга».
Также есть еще ощущение, что я смогу запроксировать произвольный урл сроком годности до 2410 года, тоесть бессрочно. При подписывании параметров всегда два правила: использовать разделители и не ставить ключ впереди при конкатенации (hash extension attack).
Проверить с планшета затруднительно, могу и ошибаться.
«финал головного мозга» ))
я привык к final, с ним все ясно и понятно
акже есть еще ощущение, что я смогу запроксировать произвольный урл сроком годности до 2410 года
не должно, timeStampExpires генерится на сервере
Можно урлы кодировать в поддомен, т.е. http://example.com/page.html подменять на http://example.com.proxy.indexisto.com/page.html — тогда достаточно подменять только абсолютные FQDN ссылки (<a href="http://..."), а относительные (<a href="/page.html") будут автоматически наследовать родительский домен и протокол.

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

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

с другой стороны удобно. Если смотришь чужой код ты точно знаешь что меняя эту переменную (которая была final) ты можешь где-нибудь накосячить и кто-то в коде ниже надеется что она final
В коде «надеяться» на final для переменной можно только в одном случае: когда переменная через замыкание передается во вложенный анонимный класс. Именно в этом случае final нужен, очевиден и будет явно потребован компилятором. Во всех остальных случаях final для переменных несет приблизительно 0 смысла.

Если в коде в какой-то момент возникает мысль обновить значение переменной, то в любом случае необходимо проверить, каким явным и неявным контрактам она должна соответстовать. Nullable? Immutable? Thread safe? Valid for context?.. Но final по сути ничего не говорит о контрактах. Только о том, что ссылка на объект не меняется. В итоге ключевое слово final на переменной вам поможет только в случае, если метод настолько большой, что визуально найти переменную вы не в состоянии, а IDE их (переменные) подсвечивать не умеет. А вы не хотите проверять контракты.

Да и в большинстве проектов если начать расставлять final на переменные — то весь код совершенно бесполезно будет пестреть ими, так как 95% переменных должны будут помечены как final.
Выше писал уже про финал головного мозга; дополню про final вообще, вдруг джуниор какой будет к собеседованию готовится :)

Когда целесообразно использовать финал?
1. Объявление полей-констант
2. Объявление полей неизменяемого (immutable) класса
3. Передача ссылки на переменную в анонимный класс
4. Запрещение наследования
5. Запрещение переопределения метода
Зарегистрируйтесь на Хабре, чтобы оставить комментарий