как передать изображение на сервер?
 

использую jquery post.

к форме со всякими параметрами, названиями и описаниями приделал поле в которое вставлять картинку <input size='30' name='file' type='file' >
думал картинка передастся, но колбэк php код - if(!isset($_POST['file'])){echo"ok";} пишет ок, значит не пришла переменная.

jquery post не умеет кидать картинки? есть ли какое то решение чтобы одновременно шла форма с текстом и картинкой?

в найденных примерах в инете отдельно отправка изображения, а мне надо чтобы вместе с другими текстовыми полями отправлялось

AJAX'ом (кроссбраузерно) нельзя передавать файлы. Используйте невидимый фрейм для этого.
Если Вы реализуете функционал под какой-то определенный браузер, Вам может помочь статья о FileAPI.

А валидация?

Что "валидация"?

А можно подробнее о некроссбраузерной передаче?

Вообще мне совершенно не понятно из-за чего разработчики браузеров (или разработчики стандартов, которым создатели браузеров должны следовать) запрещают некоторые удобства, причем эти запреты относительно легко обходятся. В пример можно привести кроссдоменный аякс, веб сокеты в опере, и вот передача файлов.

FINoM, FileAPI

можно конкретнее?

Для кроссдоменного аякса — php скрипт-посредник.
Для сокетов — флеш.
Для передачи файлов — айфрейм.

это ты их так можешь обойти, а злоумышленник как?

это другие сокеты, и почему именно в опере? В ff тоже отключили. И отключили из-за определенной уязвимости

просто стандартопейсатели были так увлечены xml и прочими мульками, что совсем позабыли про простых смертных. Или тебя смущает, что javascript не может самопроизвольно получить доступ к любому файлу на клиенсткой машине?

А как? Я как раз этим вопросов задался недавно. Как разрешить одним серверам работать с данными через php и разрешить пользоваться данными с помощью ajax пользователям зашедшим на домен, и как запретить ajax с неразрешенных доменов и получение данных со стороны неразрешенного сервера? Про ajax всё понятно, используем Access-Control-Allow-Origin, а вот ограничение на получение данных со стороны сервера я не знаю как реализовать (учитывая пункт об ajax). Чтоб было проще разобраться в том, что я хотел бы реализовать, вот некоторая структура задачи:

Сервер A (a.com) - поставщик данных
Сервер B (b.com) - один из серверов который имеет право на доступ к данным
Сервер E (e.com) - не имеющий доступа к данным.

Пытаюсь придумать, как реализовать поддержку всех пунктов вместе:
1. Дать возможность пользователю, зашедшему на b.com использовать данные с сервера a.com через ajax
2. Разрешить серверу b.com получать данные на стророне сервера, например с помощью php
3. Запретить пользователю, зашедшему на e.com пользоваться данными, которы поставляет a.com
4. Запретить серверу e.com получение данных со стороны сервера

Если я не ошибаюсь, в хроме уже достаточно давно работают сокеты и никому от этого плохо еще не стало. Эм.. А какая разница? Используется ведь один протокол, просто там реализация в браузере нативная, а там через флеш.Нет. Причем здесь это?

На самом деле нету никакой проблемы.
Нужно фильтровать запросы по http-заголовкам.

Браузер всегда сообщает адрес страницы с которой был совершен запрос (HTTP referer). И если этот запрос пришел со страницы расположенной на сервере b.com то в ответ возвращаем данные, иначе сообщение об ошибке или на свое усмотрение. Конечно это не позволяет реализовать кроссдоменный AJAX но это вполне подойдет к Script и XhrIframeProxy

В случае когда запросы приходят с серверных скриптов то отфильтровывать их еще проще. Можно фильтровать по IP, также можно придумать собственный заголовок для общения между серверными скриптами расположенными на разных серверах.

http заголовки всегда можно подменить.Да, но юмор в том, что у клиентов (посетителей) всегда будет "левый" айпи, то есть, злоумышленник, имея некоторый опыт, может легко эмулировать клиента, передавая нужного реферера, юзерагент и т. п.Эм... Почему?

Напоминает: "Смотрю в книгу - вижу фигу".

По IP фильтруем только обращения с других серверов. Причем здесь IP пользователей.

Поспешу огорчить, от данной проблемы нету 100% эликсира, всегда есть возможность притвориться браузером и послать нужные заголовки.

Это сработает только в случае не использования злоумышленником средств для замены заголосков.Согласен. Но, возможно, есть более "умный" способ, например, какой-нибудь обмен ключами или способ отправки данных, который доступен только клиенту.

использование $_SESSION , мне кажется, будет хорошей идеей

id сессии передаётся в заголовках с обеих сторон. То есть его можно тоже принять и отправить.

тогда заюзайте куки,как в вконтакте

коротко: там есть кука, UID (неважно) , коотрая является md5-хешем чего-то , чего-то и IP-адреса

если куку в ВК перехватывают и пытаются залогиниться под ней,
то конечный md5 вашего IP (или что там еще) не совпадает, далее хакера кидает на главную страницу

можно так сделать:

при заходе на страницу отправки файлов юзверю присваивается его UID, в котором хранится md5 IP, соли, USERAGENT`a ( ведь он не будет менять браузер или ОС, когда будет загружать файл)

этот UID будет в куке.

на PHP проверяем всё это , собирая такой же md5 того же списка.

хеш не совпал? какой ужас, пишем , что возникла ошибка. попробуйте повторить ещё

melky, снова повторюсь, сервер злоумышленника может отсылать куки, юзерагент, ip так же как и клиент.

если он будет "злоумышленничать" через прогу, Javascript все равно не будет исполняться

http://en.wikipedia.org/wiki/WebSock...ting_WebSocket
просто уязвимость существует, а как к этому относятся производители браузеров - другой вопрос. Как видим, мнения разделились. Может быть для твоего приложения это не важно, но это может быть важно для кого-то другого

нет, протоколы разные. И если ты используешь web socket'ы, то есть опасность того, что тебя скомпрометируют. Если ты делаешь fallback в flash, ты не решаешь проблему с уязвимость. Если исопльзуешь только флеш - решаешь, но отказываешься от возможностей web sockets

при том, что ты не обходишь политику безопасности, а передаешь файл средствами html, потому что в js такой возможности не было. И кроссдоменный ajax - это тоже скорее всего просто так изначально было реализовано, а потом стало понятно, что не учли

ip-адрес - не http-заголовок, если же речь о forwarded-for - то не стоит рассчитывать, что он корректный

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

давай уточним условия? Из твоих слов получается, что злоумышленник может получить куки любого пользователя и перехватить любую информацию. Причем есть два вида злоумышленников: 1) владелец сервера E и 2) владелец браузера, у которого нету доступа ни к A, и ни к B

x-yuri, я плохо объяснил задачу. Если сильно упростить, сервер A имеет php файл, в котором прописано:

echo '{"x":"5", "y":"21"}'

Сам пользователь может открыть у себя в браузере эту страничку и посмотреть эти данные. Ну или не может, тут разницы нету.

Владелец сервера A предоставляет услугу веб сервиса по раздаче информации об "x" и "y" платно и поддерживает актуальность этих данных, например, каждую минуту (то есть данные динамичны, постоянно заходить и копипастить нету смысла). Владелец сервера B заплатил денег владельцу сервера A, чтоб иметь возможность размещать у себя информацию, что на данную минуту x = 5, а y = 21 (может использоваться ajax или обращение из серверного скрипта). В своё время владелец сервера E зажмотился заплатить денег, значит ему нельзя обращаться к серверу B и через ajax и через php.

Интересно как это сервер злоумышленика может отсылать любые IP?
Это какой то бред.

Где написано что любые? Я говорю о том, что он может эмулировать работу клиента и, если осуществляется проверка по IP, то пользователь не сможет получить доступ к сервису через ajax. Основная мысль: использование проверки по IP не имеет смысла.

я разобрался как делать, вернее придумал и реализовал.
Я даю пользователю форму и кнопку по нажатию он выбирает у себя файл. После выбора файла он летит на сервер и обзывается именем del_тратата , и пишу имя файла в сессию, а после того как он сабмитит форму сервак убирает в названии файла del_ . И в следующий раз когда юзер выбирает файл , перед тем как его положить в папку , скри пт удаляет файлы начинающиеся на del_ чтобы не было мусора.

Вот так красиво и просто =) не понимаю ваших заморочек...

вообще-то, на самом деле можно, только не знаю, насколько просто

сможет, ты же серверы по IP банить будешь, а не клиенты. А клиентов либо через Origin, либо через Access-Control-Allow-Origin

это уродливо и сложно. Просто - это отправить форму в iframe

Ну а как определить что это сервер, если он отсылает точно такие же заголовки как и клиент? Access-Control-Allow-Origin, если я правильно понял дает возможность доступа, если в заголовках прописан соответствующий реферер.

У Вас очень слабое понимание основ функционирования сети TCP/IP.
Возможно стоит заполнить этот пробел.

Теперь насчет вопроса, у всех серверов есть IP-адресс, и у всех он разный. Вам нужно узнать IP-адресс сервера которому Вы хотите предоставлять нужную информацию. В PHP есть переменная $_SERVER['REMOTE_ADDR'], в этой переменной содержится настоящий IP-адресс ресурса который к Вам обратился. На эту переменную абсолютно не влияют заголовки которые посылает сервер.
Ну теперь все просто, смотрим значение переменной $_SERVER['REMOTE_ADDR'] и если там IP-адресс сервера который заплатил деньги то возвращаем ему echo '{"x":"5", "y":"21"}', а если нет, сообщение об ошибке или на свое усмотрение.

не надо этого определять. Разрешаешь запросы с заплативших серверов (по ip) и для клиентов заплативших серверов (по Origin)

Да, спасибо. Что посоветуете почитать (и по HTTP)?К клиенту, использующему кроссдоменный аякс это не относится?