Комментарии 35
Для более распространенных случаев, например, размещения приложений и виджетов на сторонних сайтах, хочется порекомендовать Cross-window messaging.
Не требует костылей в виде скрытого сервер-серверного общения. Не требует больших костылей, называемых проксированием. Поддержка отличная.
Не требует костылей в виде скрытого сервер-серверного общения. Не требует больших костылей, называемых проксированием. Поддержка отличная.
дак мы это и используем
вопрос в том что кто-то должен принять ваше сообщение на строннем сайте.
В нашем случае вмя история с прокси нужна для того чтобы как раз внедрить в чужой html наш JS который будет слать postMessage
window.parent.postMessage( curXpath, "*");
вопрос в том что кто-то должен принять ваше сообщение на строннем сайте.
В нашем случае вмя история с прокси нужна для того чтобы как раз внедрить в чужой html наш JS который будет слать postMessage
Небольшое замечание, может быть, полезное. Наличие/отсутствие base при генерации абсолютных адресов учитывается?
Круто! буквально вчера делал подобную вещицу. Только задача была несколько иная сделать визуальный редактор для HTML страничек. Есть HTML код, отдельно файлы стилей и скриптов. Ситли и скрипты инжектятся в хтмл + добавляется скрипт по выделению елментов и обмену сообщений все это добро пишется в iframe. У себя по HTML строим еще одну DOM. По клику из ифрейма летит через postMessage css селектором. По селектору находим елемент в DOM делаем изменеия и отсылаем обратно через postMessage в iframe. В iframe визуально отображаем изменеия. По окончании редактирования DOM сохраняем в стрингу и отправляем на сервак — все рады.
да, неплохая схема. Только не очень понял зачем в родителе держать dom клон того что в iframe (если я правильно понял). Еще вариант целиком редактор страницы заембедить в редактируемую страницу (это к комменту выше)
В ифрейме отрендеренный дом со скриптами, стилями и картинками например
real jquery code
А который мы правим и сохраняйм потом в строку имеет метки куда вставлять скрипты картинки и т.д.
Есть рендерер, который на все это смотрит и вставляет нужные скрипты и картинки.
Таким образом или имеем копию или делаем обратное преобразовние, что мне показалось, затратнее.
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» /]
Карма не дает оформить код(
[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 на серверсайде, но вполне можно на клиенте (это, конечно, не самый быстрый процесс).
В любом случае спасибо за подробный пост и ценное напоминание про безопасность.
А что будет, если через этот прокси попробовать загрузить его самого (http://highlighter.indexisto.com/?md5=6ec7rdHxUfRkrFy55jrJQA==&url=http%3A%2F%2Fhabrahabr.ru&expires=1390468360)?
Через 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)?
Сложно заменить урлы на сервер-сайде? Да одна строчка :)
Demo: zn.sergeybelove.ru
sub_filter 'google.ru' 'zn.sergeybelove.ru';
sub_filter_once off;
Demo: zn.sergeybelove.ru
я на самом деле в nginx не супер силен, финальный аккорд настраивали наши администраторы.
Я не уловил идеи, что этот конфиг делает?
Я не уловил идеи, что этот конфиг делает?
Теперь настраиваем модуль 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
www.google.ru/search?q=ngx_http_secure_link_module
Молодцы. Жаль, что Яндекс не реализовал подобную идею в Веб-Визоре.
Хм. А что по вашему Яндекс реализовал в Вебвизоре? В вебвизоре, например, есть режим, в котором проигрываемая страница грузится прямо с сайта, без всяких прокси.
Да, и правда, моя ошибка. Просто, псоле возникновения ошибки обратился к справке, в ней они предлагают попросить администора сайта убрать «Same Origin» :) А оказалось, что есть опция кэширования (правда с ограничением в 200 Кб).
Вебвизору/аналитике проще, потому что на сайте УЖЕ установлен JS с домена яндекса. Так что им достаточно в URL передать зашифрованную команду «запусти виджеты аналитики/вебвизора» и всё — проксирование в общем-то и не нужно становится.
В этот раз код для критики не выкладываете? :) Тогда покритикую практику финализации всего и вся — она не дает никаких преимуществ, но усложняет чтение и без того многословного ява кода. В самом деле, какого размера у вас методы, что вы боитесь случайно изменить локальную переменную или аргумент? Я называю этот антипаттерн «финал головного мозга».
Также есть еще ощущение, что я смогу запроксировать произвольный урл сроком годности до 2410 года, тоесть бессрочно. При подписывании параметров всегда два правила: использовать разделители и не ставить ключ впереди при конкатенации (hash extension attack).
Проверить с планшета затруднительно, могу и ошибаться.
Также есть еще ощущение, что я смогу запроксировать произвольный урл сроком годности до 2410 года, тоесть бессрочно. При подписывании параметров всегда два правила: использовать разделители и не ставить ключ впереди при конкатенации (hash extension attack).
Проверить с планшета затруднительно, могу и ошибаться.
«финал головного мозга» ))
я привык к final, с ним все ясно и понятно
не должно, timeStampExpires генерится на сервере
я привык к final, с ним все ясно и понятно
акже есть еще ощущение, что я смогу запроксировать произвольный урл сроком годности до 2410 года
не должно, timeStampExpires генерится на сервере
Пример highlighter.indexisto.com/?md5=w71PdpvimgKbITUvpld9hQ==&url=http%3A%2F%2Fya.ru&expires=13905820300
Обратите внимание на expires — оно равно Sat, 28 Aug 2410 23:51:40 GMT
Обратите внимание на expires — оно равно Sat, 28 Aug 2410 23:51:40 GMT
Можно урлы кодировать в поддомен, т.е.
Ну и многие сайты практикуют детектирование и выпрыгивание из айфреймов, нужно иметь в виду.
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 для переменной можно только в одном случае: когда переменная через замыкание передается во вложенный анонимный класс. Именно в этом случае final нужен, очевиден и будет явно потребован компилятором. Во всех остальных случаях final для переменных несет приблизительно 0 смысла.
Если в коде в какой-то момент возникает мысль обновить значение переменной, то в любом случае необходимо проверить, каким явным и неявным контрактам она должна соответстовать. Nullable? Immutable? Thread safe? Valid for context?.. Но final по сути ничего не говорит о контрактах. Только о том, что ссылка на объект не меняется. В итоге ключевое слово final на переменной вам поможет только в случае, если метод настолько большой, что визуально найти переменную вы не в состоянии, а IDE их (переменные) подсвечивать не умеет. А вы не хотите проверять контракты.
Да и в большинстве проектов если начать расставлять final на переменные — то весь код совершенно бесполезно будет пестреть ими, так как 95% переменных должны будут помечены как final.
Если в коде в какой-то момент возникает мысль обновить значение переменной, то в любом случае необходимо проверить, каким явным и неявным контрактам она должна соответстовать. Nullable? Immutable? Thread safe? Valid for context?.. Но final по сути ничего не говорит о контрактах. Только о том, что ссылка на объект не меняется. В итоге ключевое слово final на переменной вам поможет только в случае, если метод настолько большой, что визуально найти переменную вы не в состоянии, а IDE их (переменные) подсвечивать не умеет. А вы не хотите проверять контракты.
Да и в большинстве проектов если начать расставлять final на переменные — то весь код совершенно бесполезно будет пестреть ими, так как 95% переменных должны будут помечены как final.
Выше писал уже про финал головного мозга; дополню про final вообще, вдруг джуниор какой будет к собеседованию готовится :)
Когда целесообразно использовать финал?
1. Объявление полей-констант
2. Объявление полей неизменяемого (immutable) класса
3. Передача ссылки на переменную в анонимный класс
4. Запрещение наследования
5. Запрещение переопределения метода
Когда целесообразно использовать финал?
1. Объявление полей-констант
2. Объявление полей неизменяемого (immutable) класса
3. Передача ссылки на переменную в анонимный класс
4. Запрещение наследования
5. Запрещение переопределения метода
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Доступ к контенту iFrame с другого домена