Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Сокеты? Не, не слышал об этом =)
del
А зачем столько наворотов? Реально хватило бы просто реализации pubsub, без адресации. Дальше все можно было бы строить поверх этого.
чем postmessage не устроил?
Если мне память не изменяет, то postMessage требует указатель на объект окна, которому передается сообщение. Потому этот метод и используется, как правило, для коммуникации с iframe или окнами/вкладками, которые были открыты скриптами (когда получаем указатель из метода window.open()) — в этом случае всё гладко.
А как нам получить указатель на вкладку/окно, если, например, пользователь руками дважды набрал адрес нужной страницы в разных окнах, но в одном браузере?
А как нам получить указатель на вкладку/окно, если, например, пользователь руками дважды набрал адрес нужной страницы в разных окнах, но в одном браузере?
для коммуникации с iframe или окнами/вкладкамиС вкладками? Можно подробнее?
Кидаем тут в консоль:
В открывшемся окошке гугла кидаем в консоль:
Снова возвращаемся сюда и кидаем в консоль:
В консоли гуглового окошка наблюдаем надпись «MyEvilMessage».
Про это подробнее написано вот тут.
var WindowHandler = window.open( 'http://google.com' , '_blank' );
В открывшемся окошке гугла кидаем в консоль:
function listener( Event ) {
console.log( Event.data );
}
if ( window.addEventListener ){
window.addEventListener( "message" , listener , false );
} else {
window.attachEvent( "onmessage" , listener );
}
Снова возвращаемся сюда и кидаем в консоль:
WindowHandler.postMessage( 'MyEvilMessage' , '*' );
В консоли гуглового окошка наблюдаем надпись «MyEvilMessage».
Про это подробнее написано вот тут.
На этот случай есть хак:
При открытии вкладки (или по другому событию) она меняет свой
Тут есть, конечно, куча ограничений, и самое главное из них — мобильный сафари, он замораживает неактивную вкладку, так что onstorage (и, если мне не изменяет память, даже банальный setTimeout) не выполнится, пока она не станет активной. Выходом из этого могли бы быть Shared Workers, но они тоже были выпилены из этого чудесного браузера.
При открытии вкладки (или по другому событию) она меняет свой
window.name на какую-нибудь псевдо-уникальную строку и отсылает её через localStorage. Другие вкладки (если есть) ловят onstorage и запускают var hWnd = window.open("", "{{имя окна}}"), получая ссылку на её window.Тут есть, конечно, куча ограничений, и самое главное из них — мобильный сафари, он замораживает неактивную вкладку, так что onstorage (и, если мне не изменяет память, даже банальный setTimeout) не выполнится, пока она не станет активной. Выходом из этого могли бы быть Shared Workers, но они тоже были выпилены из этого чудесного браузера.
Shared Workers вообще бы решили всё и не пришлось бы городить огород. Но на тот момент, когда писалась библиотека, их поддержка была чуть менее, чем никакая. Сейчас положение, конечно, лучше, но всё ещё где-то на уровне «м-да»… :)
И как раз для борьбы с заморозками неактивных вкладок (и отсутствием реакции на события хранилища) я и использовал обычный Worker, который, работая фоном, банально пингует вкладку изнутри. Такая беда не только в мобильном сафари.
И как раз для борьбы с заморозками неактивных вкладок (и отсутствием реакции на события хранилища) я и использовал обычный Worker, который, работая фоном, банально пингует вкладку изнутри. Такая беда не только в мобильном сафари.
От оно как! Надо с самопингующими вёркерами поэкспериментировать, спасибо. Видимо, у них какие-то особые привилегии.
Согласен, ситуция с шаредами аховая. Но какой-нибудь метод вроде
Согласен, ситуция с шаредами аховая. Но какой-нибудь метод вроде
window.getSameDomainWindows(), желательно синхронный, и парочка событий были бы даже лучше. Как вы думаете, может стоит сделать proposal какой-нибудь Мозилле?Предложение Mozilla сделать, думаю, стоит, но… что-то мне подсказывает, что это будет уже далеко не первое предложение о внедрении подобного функционала. Потому что судя по опросу в конце топика, почти половина программистов сталкивается с необходимостью внедрять подобную коммуникацию. Плюс на том же stackoverflow видел кучу вопросов по этой теме ещё с бородатых годов (когда народ ещё через Cookies и setInterval это всё пытался сделать).
Стало быть вопрос стар, как мир. Почему не внедрили до сих пор? — Вероятно, есть какие-то причины.
И первое, что приходит на ум — это вероятные проблемы с безопасностью. Потому что тут, как минимум, существует серьезная дыра, когда при наличии банального XSS лишь на одной из страниц, удар может прийтись уже по любой части сайта через другие открытые вкладки.
А теперь представим ситуацию, что на такую XSS попался админ, у которого в данный момент в соседней вкладке открыта админка. Даже если на сайте реализованы все возможные системы нивелирования угроз со стороны данных, которые можно вытянуть через XSS, или реализованы даже какие-нибудь одноразовые ключи на каждое действие в админке (аля, «скрытая капча», чтоб только напрямую с админки можно было выполнять системные скрипты), то все эти средства защиты идут прахом, потому что по факту получается, что через XSS в какой-нибудь подписи на форуме, злоумышленник напрямую действует «руками админа» через админский браузер в админке сайта, а админ этого даже не заметит, потому как все действия будут происходить в неактивной вкладке.
Так что, всё же, палка о двух концах, как мне кажется, и внедрять это на нативном уровне — опасно.
Стало быть вопрос стар, как мир. Почему не внедрили до сих пор? — Вероятно, есть какие-то причины.
И первое, что приходит на ум — это вероятные проблемы с безопасностью. Потому что тут, как минимум, существует серьезная дыра, когда при наличии банального XSS лишь на одной из страниц, удар может прийтись уже по любой части сайта через другие открытые вкладки.
А теперь представим ситуацию, что на такую XSS попался админ, у которого в данный момент в соседней вкладке открыта админка. Даже если на сайте реализованы все возможные системы нивелирования угроз со стороны данных, которые можно вытянуть через XSS, или реализованы даже какие-нибудь одноразовые ключи на каждое действие в админке (аля, «скрытая капча», чтоб только напрямую с админки можно было выполнять системные скрипты), то все эти средства защиты идут прахом, потому что по факту получается, что через XSS в какой-нибудь подписи на форуме, злоумышленник напрямую действует «руками админа» через админский браузер в админке сайта, а админ этого даже не заметит, потому как все действия будут происходить в неактивной вкладке.
Так что, всё же, палка о двух концах, как мне кажется, и внедрять это на нативном уровне — опасно.
Ваша правда. При достаточно расхлябанной защите можно и сейчас увести админские куки или открыть админку в ифрейме, а такой метод давал бы слишком много удобства.
Но с другой стороны можно заложить необходимость явного включения автообнаружения для каждой вкладки, скажем, не выполнил
Ещё один минус межвкладочного взаимодействия через ссылку на другое окно — возможность создать адскую утечку памяти, от которой даже F5 не спасёт. Но тут уже надо программисту просто знать, что он делает.
Но с другой стороны можно заложить необходимость явного включения автообнаружения для каждой вкладки, скажем, не выполнил
window.Domain.enableAutoDiscovery(true), ссылку из другого окна не получишь.Ещё один минус межвкладочного взаимодействия через ссылку на другое окно — возможность создать адскую утечку памяти, от которой даже F5 не спасёт. Но тут уже надо программисту просто знать, что он делает.
Тоже такое делал: github.com/StreetStrider/XTab
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Библиотека для обмена событиями, данными и задачами между вкладками браузера