Muslim Mamaev, Как я писал выше -- " сайт не примет запросы если в них не будет заголовков user-agent и x-requested-with". Делайте POST запросы с этими заголовками, я даже скрин прикрепил с их значениями и получите искомый json.
Muslim Mamaev, Боюсь, что за вас тут вряд ли кто-то будет делать ваши задачи. Тут вы можете только спросить "как", но реализация ваших задач остаётся за вами. Могу лишь подсказать еще -- читайте про CURL, как отправлять запросы на сервер(в вашем случае POST запросы). Далее, когда получите json из запроса, то декодируйте его с помощью функции json_decode и работайте с полученными данными.
Во первых, SET стоит в изначальном запросе ТСа. SET и INSERT в MySQL вполне себе сочетаемы. Во вторых, я обозначил переменную plus_days в коде, ДО sql запроса, определив ей определенное значение. О какой инъекции тогда вы говорите? Если уж переменная будет приниматься в скрипт извне, то это уже дело автора, как он её будет обрабатывать. Если же речь о самом способе построении запроса через конкатенацию строк, то это к данному вопросу не имеет отношения, я не пытаюсь учить ТСа тому, о чем он не спрашивает, я лишь дополнил его изначальный запрос. Поэтому ваши претензии мне непонятны.
Антон Горецкий, Да, разумная схема. Запрос с инфы с сервера это просто, главное как это потом сравнивать с тем что загружается на клиенте. Тут, как раз, blob помогает, как я понял. В общем и целом понятно. Если вынесете свой коммент в ответы, то отмечу как решение. Спасибо!
Dark_Dante, Если не секрет, почему не стоит? На сколько мне известно, json_encode выигрывает в скорости у serialize, отсюда и мой пример. Какие есть "против" именно json_encode/decode? (не спора ради, а любопытства для)
Adamos, для ознакомления: https://stackoverflow.com/questions/7485111/weird-...
Гугл передает #, фейсбук #_=_. И даже если в коде урл перенаправления будет чистым, то это добавится к нему после редиректа и повлиять на это нельзя, без костылей на фронте, уже по факту перенаправления. Вот такая вот интересная штука, вот только "метод болвана" тут совершенно бессилен.
Дмитрий, Там функционал работает иначе, как стандартно происходит авторизация через соц. сеть. Есть кнопка "авторизоваться через facebook", к примеру. На кнопку нажимаем -- переходим на фейсбук, вводим свои логин с паролем, разрешаем доступ приложению к своим данным, после этого фейсбук уже отправляет переменную токена гетом, с перенаправлением на страницу-обработчик. Ну и далее через curl забор данных в обработчике и далее сабжевый редирект. Так что тут js запросы в принципе не юзабельны. И редирект на реф тоже, т.к. реф тут это соц. сеть.
Adamos, Вот как раз предположения такого "гадства" я и ищу. Я только что проверил это дело так:
header("http://site.ru");
exit;
Т.е. переменную вообще убрал и написал ручками строку. И опять же перенаправляет на site.ru#
А страница на site.ru пустая, без всякого кода. Вот какая тут еще может быть инфа?
Adamos, А больше информации и нет. Есть переменная url, в нее записано значение site.ru, а перенаправление происходит на site.ru# Все. Нет фронтенда там, вообще.
Вы невнимательно прочитали. Во втором фрагменте кода, что я привел выше, я показываю, что проверяю в каком виде находится url в сессии; он в нормальном виде, ничего лишнего нет. А фронт в этом не участвует: в скрипт приходят данные с фейсбука, к примеру, потом происходит перенаправление. Никаких a href и никакого js.
