Обратный вызов JSONP не выполняется при выполнении в localhost
Это работает (отображает 15) с компилятором Microsoft C (без stdint.h, поэтому я использовал typedef):
#include <stdio.h>
typedef unsigned char uint8_t;
int main(void) {
uint8_t i = 0;
i = (uint8_t)(i - 1) % 16;
printf("i: %d\n", i);
return 0;
}
Причина 255 в том, что (i - 1) повышен до integer и целочисленное деление, используемое для% в C, округляет до нуля вместо отрицательной бесконечности (округление до отрицательной бесконечности - это то же самое, что и в математике, естествознании и других языках программирования). Так что для C% равен нулю или имеет тот же знак, что и дивиденд (в данном случае -1% 16 == -1), в то время как в математике по модулю ноль или тот же знак, что и у делителя.
2 ответа
Я собираюсь дать ответ там ; после некоторого размышления я пришел к своим собственным выводам.
Возможно, это функция безопасности, которая реализована, чтобы помешать веб-сайту в Интернете вызывать службы JSONP, запущенные на клиентской машине.
Веб-сайт может просто просмотреть список портов и продолжать вызывать localhost для разных портов и путей. «Localhost» - одно из немногих имен хостов DNS, которые имеют динамическое значение в зависимости от того, когда и где его запрашивают, что делает потенциальные цели уязвимыми. И да, тот факт, что добавление точки (.) К 'localhost' ('localhost.') Дает рабочий обходной путь, действительно обнаруживает уязвимость системы безопасности, но предлагает [предварительный] обходной путь для целей разработки.
Лучшим подходом является сопоставление IP-адреса обратной связи с новой записью имени хоста в файле hosts, чтобы он работал локально, не подвергался «исправлению» обновлением браузера и не работал где-либо еще, кроме рабочая станция разработчика.
У меня аналогичная проблема. Большинство решений, которые я пробовал, работают с IE (7), но мне трудно заставить Firefox (3.5.2) играть в мяч.
Я установил HttpFox, чтобы посмотреть, как меняются ответы сервера интерпретируется на клиенте, и я получаю NS_ERROR_DOM_BAD_URI. Моя ситуация немного отличается от вашей, поскольку я пытаюсь вызвать JSONP-вызов на тот же сайт, с которого пришла страница хостинга, а затем этот вызов отвечает перенаправлением 302 на другой сайт. (Я' m, используя перенаправление как удобный способ получения файлов cookie из обоих доменов, возвращаемых в браузер.)
Я использую jQuery, и изначально я пытался выполнить стандартный вызов AJAX через $ .ajax (). Я решил, что, поскольку первоначальный запрос был направлен на тот же сайт, что и страница хостинга, Firefox просто последует ответу 302 на другой домен. Но нет, похоже, он не справился с защитой XSS. (Обратите внимание, что вопреки тому, что подразумевает Возврат перенаправления в ответ на запрос XHR , jQuery следует перенаправлению 302 для стандартного вызова dataType = "json": перенаправление на тот же домен работает нормально; перенаправление на другой domain генерирует NS_ERROR_DOM_BAD_URI в браузере.) Кроме того, я не понимаю, почему перенаправления одного домена 302 на другие домены нельзя просто отслеживать - в конце концов, это страница хостинга ' s домен, который выдает перенаправление, так почему ему нельзя доверять? Если вас беспокоят атаки с использованием сценариев инъекций, тогда маршрут JSONP в любом случае открыт для злоупотреблений ...
$ .getJSON () jQuery с? Callback =? суффикс также не работает в Firefox с той же ошибкой. Как и при использовании $ .getScript () для прокрутки моего собственного тега JSONP