JSONP и междоменные запросы - как обновлять / манипулировать, а не просто читать - PullRequest
1 голос
/ 30 октября 2008

Итак, я читаю «Искусство и наука о Javascript», которая является хорошей книгой и имеет хороший раздел по JSONP. Я прочитал все, что мог об этом сегодня, и даже просматривал каждый вопрос здесь, на StackOverflow. JSONP - отличная идея, но она, кажется, только решает «ту же проблему происхождения» для получения данных, но не решает ее для изменения данных.

Я просто пропустил все блоги, которые говорили об этом, или JSONP не решение, на которое я надеялся?

Ответы [ 2 ]

3 голосов
/ 30 октября 2008

JSONP приводит к тому, что тег SCRIPT генерируется на другом сервере с любыми параметрами, которые могут потребоваться в качестве запроса GET. например,

<script src="http://myserver.com/getjson?customer=232&callback=jsonp543354" type="text/javascript">
</script>

Технически ничто не мешает такому запросу изменить данные на сервере, например указав newName = Тони. Ваш ответ может быть, было ли обновление успешно или нет. Вы будете ограничены тем, что можете разместить в строке запроса. Если вы собираетесь использовать этот подход, добавьте некоторый случайный элемент в качестве параметра, чтобы прокси не кэшировал его.

Некоторые люди могут подумать, что это идет вразрез с тем, как должны работать GET, то есть они не должны вызывать изменение данных.

0 голосов
/ 30 октября 2008

Да, и, честно говоря, я хотел бы придерживаться этой парадигмы. Тем не менее, я мог бы изменить правило и сказать, что запросы, которые не изменяют / обрабатывают данные CRUCIAL, будут доступны через вызовы GET ... хм ...

Например, я создаю систему корзины покупок, и я думаю, что разрешение на добавление / удаление / и т.д. элементов в / из корзины может быть очень легко раскрыто с помощью GET, поскольку даже если вы можете изменять данные, вы не можете сделать что-нибудь критическое с этим. Если кто-то злонамеренно добавит 1000 мониторов с плоским экраном в вашу корзину для покупок, будет хотя бы один шаг проверки, который НЕ будет уязвим для любых атак (стандартная страница ASP.NET на тот момент, с проверкой и всем этим джазом).

По мнению кого-либо, это хорошее / работоспособное решение?

...