- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Доброе утро.
Задача такая: нужно при открытии посетителем веб страницы домена А из браузера посетителя сделать GET запрос на домен Б, вытащить из текста кусочек, и далее его использовать в скриптах домена А. Именно из браузера.
Изначально все это реализовал на PHP, перед релизом оказалось что на localhost все пашет, а на хостинге - нет, пришлось функцию отключить. Причина - этот самый код зависит от IP клиента, потому запрашиваться с домена Б должен исключительно самим клиентом с его адреса. Классический для таких случаев хак с подстановкой X-Forwarded-For конкретно на этом сайте не канает.
Перекопал все по теме Javascript / XDomainRequest / XMLHttpRequest - не реально, запрос осуществляется (сниффер не врет) но результат выполнения (ответ) не получен, JS выдает ошибку. Такая вот хитрая защита от хакеров - вместо блокировки запроса блокируется передача ответа скрипту (насколько я понимаю, уже самого запроса достаточно во многих случаях, тем более POST)...
Есть мысль реализовать это на Flash - невидимый апплет, который будет получать из <param> адрес страницы, закачивать ее, парсить нужный кусок из кода и передавать его какой-то javascript функции. Такой метод сработает или во Flash сокеты тоже урезаны?
Так GET запрос можно делать просто curl'ом без каких-либо проблем, и отдавать его в js, к примеру ajax'ом.
Сайт Б вы контролируете? Если да - то, насколько я в курсе, можно там добавить несколько заголовков в ответ сервера. чтобы у Js и flash был к этому домену доступ.
Или даже через jsonp всё сделать.
Если доступа к сайту Б у вас нет - то вряд ли что-то получится.
Насколько помню, для флеша надо тоже что-то прописывать на домене Б - crossdimain.xml вроде с разрешением на дергание информации.
CURLом не канает, описал проблему в 1м абзаце. Так и было сделано, но строка которую я должен забирать с сайта Б привязывается к REMOTE_ADDR с необратимым шифрованием, потому строка запрошенная с IP моего хостинга бесполезна в браузере клиента, имеющего отличный от него IP адрес.
Нет, сайт Б не я контролирую, потому
добавить не могу туда.
Если бы я его контролировал - задача бы решалась без междоменных запросов.
А если я буду запрашивать не готовым HTTP запросом, а на голых сокетах?
Вроде бы там есть Socket class с методом connect и событием socketData, и куча многопользовательских игр Вконтакте, которые ломятся на сервера разработчиков игры.
А если я буду запрашивать не готовым HTTP запросом, а на голых сокетах?
тоже crossdomain.xml в корневом каталоге сервера нужен с правами попробуйте через WebSocket если конечно удаленный сервер поддерживает и разрешает кросс-доменные запросы.
Да, с Flash это феерический бред, кому нужна урезанная реализация функций в неполноценном языке программирования. А Java вообще не вариант - он сейчас мало у кого работает в браузерах.
За идею Websocket спасибо. Запрос CONNECT / GET уходит, сервер отвечает обычным HTML (не поддерживается, видимо) и этот ответ дальше никуда не идет - события onopen и onmessage не вызываются. Видимо, опять мимо.
Что-то мне подсказывает что этот функционал нужно выносить в десктопный клиент для постоянной аудитории сайта... В браузерах все слишком запрещено.
В браузерах все слишком запрещено.
ну как бы по делу...
curl + proxy
Спасибо за старание, но 1, 2 и 4й пост Вы не читали.
Ладно, смотрю тему можно закрывать. Отговорили меня даже пытаться это делать на Flash.