window.name как транспорт данных: допустимый подход?

Обзор и исходный вопрос

window.name— интересный зверь. Описание MDN намекает на первоначальный замысел:

Имя окна используется в основном для установки целей для гиперссылок и форм. Windows не обязательно должны иметь имена.

Итак, это означает, что мы можем открыть консоль в этом окне и написать:

var win = window.open('http://google.com', 'el goog');

...а затем пропустить через блокировщик всплывающих окон, который должен открыть google.com в окне с именем "el goog". Я не могу получить доступ к свойству nameдля winиз-за политики того же источника, но если я открою консоль в новом окне и наберу name, Я возьму "el goog".

Если я отправлю окно обратно в домен, из которого я его открыл (в данном случае stackoverflow.com), я могу получить свойство name, и оно не изменится.

win.location.replace(location.href);
win.name; // "el goog"

Это означает, что мы можем иметь своего рода междоменное хранилище сеансов, установив свойство nameокна.

Если бы google.com изменилзначение window.nameдо того, как окно было отправлено обратно в исходный домен, мы бы увидели новое значение вместо "el goog ." Это можно использовать в качестве междоменного транспорта данных, аналогичного JSONP или CORS.

Я немного поискал, чтобы попытаться найти больше информации, и, по-видимому, додзё считает, что это законныйтранспорт.Но как-то это меня не совсем успокаивает. Итак, мой вопрос: используют ли авторитетные сайты window.nameв качестве транспорта данных? Я думаю, это будет легко обнаружить, потому что в их документах будет сказано что-то вроде «добавить «обратный вызов» в строку запроса для JSONP или добавить «что угодно» для window.name,», но я никогда не видел ничего подобного. Кто-нибудь действительно замечал это в дикой природе?


Альтернативный вопрос

Возможно, никто на самом деле не использует эту технику; если это правда, то (как указал Роб В.) на поставленный выше вопрос нет ответа. Итак, мой альтернативный вопрос: какие проблемы с этим подходом? Это может помочь объяснить, почему он на самом деле не был принят.

Насколько я понимаю, у этого подхода есть как минимум два преимущества перед JSONP.

  • С помощью JSONP вы доверяете скрипту из иностранного источника для запуска в вашем домене. С window.nameлюбые сценарии, включенные вредоносным сайтом, будут выполняться в их собственном домене.

  • При использовании JSONP нет возможности передавать большие данные (что-то слишком большое для URL) и нет возможности выполнить HTTP POST. С помощью window.nameмы можем публиковать произвольные данные любого размера.

Каковы недостатки?


Пример реализации

Вот очень простой пример реализации клиента. Это не обрабатывает запросы POST, только GET.

function fetchData(url, callback) {
    var frame = document.createElement('iframe');
    frame.onload = function() {
        frame.onload = function() {
            callback(frame.contentWindow.name);
            frame.parentNode.removeChild(frame);
        }
        frame.src = 'about:blank';
    }
    frame.src = url;
    document.body.appendChild(frame);
}

// using it

fetchData('http://somehost.com/api?foo=bar', function(response) {

    console.log(response);

});​

Я установил скрипт, чтобы протестировать его здесь. Он использует этот скриптв качестве тестового сервера.

Вот немного более длинный пример, который может выполнять POST-запросы: http://jsfiddle.net/n9Wnx/2/


Резюме

Насколько я могу судить, window.nameне прижился как транспорт данных. Интересно, правильно ли мое восприятие (отсюда исходный вопрос), и если да, то интересно , почемуэто так. Я перечислил несколько преимуществ, которые window.nameимеют по сравнению с JSONP. Может ли кто-нибудь определить некоторые недостатки, которые могли помешать внедрению этого метода?

Более конкретно, может ли кто-нибудь дать мне вескую причину, почему я не должен использовать winow.nameв качестве транспорта данных?

45
задан Dagg Nabbit 26 March 2013 в 17:08
поделиться