[laimas]

/denwer/errors/phperror_js.php

Денвер в утиль, он давно умер, скачивайте Open Serever. Это такой же компактный не требующий инсталляции и работающий с чего угодно как и Денвер локальный сервер, но с гораздо большими возможностями и более удобный. Проект живой и постоянно обновляется как по мере выхода новых версий компонентов, так и в плане новых возможностей.

$mime = array('image/png', 'image/jpeg'); //переделал строку с вашим кодом, а то он ругался на кв ковычки

Квадратных кавычек нет. Ругается потому, что вы используете версию РНР ниже 5.4, в которых нельзя объявить массив литерально [], а только как array(). Вы должны использовать ту версию языка, которая доступна на реальном сервере. И если доступны версии 5.4 и выше, то ориентируйтесь на них, в них больше возможностей, что позволяет писать код более компактным, ну и конечно же, это устранение "болезней" предыдущих версий.

Поэтому если я далее пишу код, то ориентируюсь на версию не ниже 5.5, учитывайте это.

НО поскольку для меня это темный лес, и все функции для меня новые.

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

Сказанное выше, это рекомендации, и это я советую сделать. А то, что далее написано, это вы должны делать и не потому, что я советую, а вы уважаете. Все что ниже, вы обязаны делать исходя из требований к безопасности кода.

**********

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

Война и мир. Ремейк. Том 62

Ужастики

Также я загружаю фото из карточки УЖЕ созданного товара, а следовательно не надо проверять есть он в БД или нет. Он есть 100%.

Второе предложение можно принять за постулат, а вот первое будет постулатом только пока выборка из базы живет на сервере. Как только результат выборки отдали клиенту, можно смело сказать, что она уже не принадлежит базе потому, что нет такой же 100-процентной гарантии, что она вернется на сервер в том же виде.

Существует опасный вид атаки называемый "человек посередине" (Man in the middle, MITM), которой подвержены и безопасные соединения, а обычный http тем более. Вы отдали клиенту "У нас все замечательно!", а клиент может получить "Кошка сдохла." и вернет вам "Примите наши соболезнования." Кроме этого в сети шарятся кучи ботов сканирующие страницы с формами и отсылающие их копии серверу жертве.

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

Дихлофос

Защита, это вопрос серьезный, широкий, понимание и знания будут накапливаться, нужно только обязательно интересоваться этими вопросами. Но уже в самом начале практики написания кода нужно выполнять элементарные действия:

- сервер отдавая данные клиенту не должен допустить на нем XSS атаки, пропуская вывод данных полученных извне через htmlspecialchars()
- не использовать в именах полей формы имена SQL таблиц, а если используются, то только их часть после префикса
- данные поступающие на сервер извне подлежат обязательной проверке/фильтрации
- блокировать вывод ошибок и предупреждений на страницах на удаленном сервере

Как пример, а не обязательное требование использовать.

Надежный пароль 123456789, это уже анекдот, но тем не менее такое есть и не в единственном случае. Сюда же можно отнести и именование полей форм: name, first_name, last_name, phone, email, login, password, ... или вариации этого. Боты такие формы любят, что и для чего ясно, и китайца "арендовать" не нужно для снятия слепка с формы.

Как можно продихлофосить. Например, все имена формы содержат первичный ключ, который есть хеш случайного значения, который формируется сервером и запоминается на нем. Вторичные ключи, это индексы реальных имен, которые могут быть связаны и с именами полей SQL таблицы, и прочими другими данными, и которые знает только сервер. То есть имена полей будут выглядеть так:

name="4a0d42e025eb49edf7f292be67c1099f[5]"
name="4a0d42e025eb49edf7f292be67c1099f[1]"
name="4a0d42e025eb49edf7f292be67c1099f[3]"
....
name="4a0d42e025eb49edf7f292be67c1099f[9]"

При каждом запросе формы первичный ключ меняется. Ключ живет только на время сессии, а также удаляется после приема формы. То есть, нельзя будет отправить вторично эту форму, север ее просто не примет, так как ключа ее на сервере не будет.

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

Рекогносцировка

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

В современном HTML информирование и проверку можно возложить на браузер без всяких затрат на написание кода. Но в форме загружающей файлы для таких полей нативной проверки нет. Более того, если сервер не сообщит клиенту параметров по загрузке, то и пенять не на кого. Клиент должен быть извещен о типах файлов, которые примет сервер. Эти типы нужно перечислить в атрибуте accept поля file. Умные браузеры в диалоге выбора файлов будут отображать файлы только указанных типов. Клиенту также передается максимальный размер файла, который можно загрузить, общее количество файлов для загрузки за один раз, и максимальный размер данных, который можно передать методом POST. Эти данные сервер должен получить из настроек сервера, передав их клиенту.

Если файлы, это графика и предполагается ее обработка на сервере, то клиенту должно быть передан размер памяти доступный под такую обработку.

При выборе файлов, клиентский сценарий должен проверять выбранное на соответствие типу, размеру, количеству и соответствие общего размера выбранного разрешенному для загрузки. А если предполагается работа с графикой, то получать разрешение выбранных файлов, рассчитывать объем памяти под них требуемый, чтобы он не был больше допустимого сервером. Либо просчитав возможности сервера, не разрешать к загрузке графику выше определенного разрешения.

********

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