Привет!
Купил небольшой фотосток. Но возник вопрос: Как безопасно хранить изображения на сервере.
Текущая реализация софта подразумевает хранение всех фотографий в одной папке PHOTO, которая размещается в корневом каталоге. Имена файлов превюшек и готовых отличаются только на одну -две буквы (стандартный алгоритм).
Т.е. можно посмотреть наименование файла превьюшки, поменять p_имяфайла.jpg на s_имя.jpg и не за что платить не надо

Как можно бороться с этой ситуацией? понятно что надо перенести каталог в зоне выше http, но как потом доставать все оттуда?

Если хранить полноразмерные за пределами htdocs, то можно после оплаты копировать их во временную папку, доступную по http. Имена делать какие-нибудь случайные. Временную папку чистить, например, раз в час удалять те файлы, которые были созданы более суток назад.

Как вариант можно просто изменить формат имени файла для полноразмерных фотографий так, чтобы оно содержало случайную часть: s_имяфайла_случайнаячасть.jpg
Привязки полноразмерных к превьюшкам хранить в базе данных.

sukebe писал(а):

Если хранить полноразмерные за пределами htdocs, то можно после оплаты копировать их во временную папку, доступную по http.

А вот этого, за редкими исключениями, делать не следует.

Элементарно, Ватсон. Используйте абсолютные пути, PHP это может.
PHP-скрипт:



при условии, что корень HTTP - /usr/local/httpd/htdocs/

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

Бaзиль, начинать нужно с другого -- с начала. С вопроса "кому и когда должно быть доступно полноразмерное изображение".

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

Бaзиль, имя "AlexeyV" -- это твой второй аккаунт на этом форуме?

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

Crazy, че-т я не очень понимаю. Наверное, еще не проснулся

Crazy, достал уже всех своими точностями и неточностями )))

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

AlexeyV, а как называется Ваш скрипт?
Crazy, поясните, пожалуйста:

Crazy писал(а):

Бaзиль, Кроме того, в твоей фразе "пользователю, который это оплатил" есть одна принципиальная ошибка и одна важная неточность.

??

WayBe, поясняю:

1. Ошибка: пользователь оплатил -- это когда деньги поступили на счет. Скрипт на сайте об этом ничего не знает. Признак должен быть более внятный: в базу занесена запись об оплате, в каталоге повился специальный файл и т.п.

2. Важная неточность: как мы определяем, что перед нами пользователь, который это оплатил? Это не так уж очевидно. Например, в варианте sukebe это любой пользователь, который догадался зайти в указанную папку.

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

ага. ну да..
Вот по теме: http://phpclub.ru/detail/article/2001-01-16

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

Jamakaser писал(а):

Планирование великая вешь.

Да, великая. И прийти к варианту, о котором рассказал Crazy. А что ещё очевиднее -- не надо изобретать велосипед или забивать микроскопом гвозди, то бишь "планировать".

tentoys писал(а):

А что ещё очевиднее -- не надо изобретать велосипед или забивать микроскопом гвозди, то бишь "планировать".

Ваше личное дело.

Jamakaser, дабезпроблем.
КОнечно это моё личное дело. Однако, не сомневаюсь, что подобные вопросы уже были спланированы (had been, ага), неоднократно и неединожды и что впустую тратить грифель и изводить бумагу? Вы понимаете, о чём я?

tentoys,

Понял, понял. Согласен. Но подумать, подходит в данном случае вот та фигня или лучше вот такую поебень... тоже считаю нужным

Crazy писал(а):

WayBe, поясняю: 2. Важная неточность: как мы определяем, что перед нами пользователь, который это оплатил? Это не так уж очевидно. Например, в варианте sukebe это любой пользователь, который догадался зайти в указанную папку.

Пользователь, который зайдет в указанную папку, получит 403-ю ошибку.

Таким образом, для того чтобы что-то скачать, пользователю недостаточно знать имя папки. Не зная имени файла, он ничего скачать не может.

Вариант с архив не плох, но не юзер-френдли.

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

sukebe писал(а):

Пользователь, который зайдет в указанную папку, получит 403-ю ошибку.

С какого перепугу? Цитирую:

Цитата:

можно после оплаты копировать их во временную папку, доступную по http. Имена делать какие-нибудь случайные. Временную папку чистить, например, раз в час удалять те файлы, которые были созданы более суток назад.

Не вижу в тексте ни одной причины, по которой должна возникнуть error 403.

Crazy, подразумевалось, что веб-сервер настроен так, чтобы не отдавать пользователю список файлов. Ведь, согласитесь, иначе его настраивать в рассматриваемом случае просто нет смысла.

Если это было не очевидно, то что ж поделать... извините.

sukebe писал(а):

Crazy, подразумевалось,

Hint: все люди подразумевают разное. А телепаты, как всегда, в отпуске.

А не проще в имени файла (пути) использовать связку хэш+контрольная сумма и пропускать это все через специальный скрипт? Вобщем вариантов очень много.

deleon, какую именно проблему решает предлагаемый тобой подход?

Crazy писал(а):

deleon, какую именно проблему решает предлагаемый тобой подход?

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

/AGF564FGD5465J/p12345765.jpg - превьюшка
/FJHBJ765JGFD9H/o12345765.jpg - оригинал

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

deleon, куда проще вариант, который упоминает sukebe -- добавить рандомный компонент и хранить привязку в базе.

Crazy писал(а):

deleon, куда проще вариант, который упоминает sukebe -- добавить рандомный компонент и хранить привязку в базе.

Я ничего не оспариваю. Просто привел вариант, который при правильной реализации, тоже достаточно живуч.

Проблема в том, что оба эти варианта не решают проблему защиты от несанкционированного скачивания. Простейший пример: у Васи медленный интернет и он пришел к Пете, чтобы слить свои картинки. Вставил флэшку, запустил браузер, залогинился и скачал на флэшку оплаченные файлы. И их URL'ы легли в историю браузера, в логи прокси и т.п.

Затем Вася закрывает браузер, вынимает флэшку и уходит. А Петя достает из истории URL и скачивает себе копию файла.

Либо еще проще: вначале пользователи X и Y покупают картинку, а потом где-нибудь на форуме появляется анонимная ссылка.

Если в моем варианте в зашифрованном имени файла (пути) хранить следующую информацию:
- user ID
- Date start (or date expiration)
- Имя файла

То описанную проблему можно легко решить.
По идее можно в базе хранить реальные данные пользователя, купленного файла и дату валидности ссылки. А в ссылке зашифровать ID записи в базе.
Невижу никаких сложностей в надежной реализации данного подхода.

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

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

deleon писал(а):

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

в избранное

deleon, не надо слишком все усложнять.

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

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

Гм...
Хранить картинки в запароленном архиве — минимум сложнее для пользователя, да и не кроссплатформенно — зажали gzip'ом, а у пользователя его может быть минимум не установлено, а в худшем случае — вообще не существовать для его операционки (утрирую, но всё-же).

Хранить в пределах htdocs «as is» (пусть даже с трижды зашифрованными именами), и давать пользователю direct link — значит, открыть свободный доступ к картинкам вообще всем. Линки на форумах точно появятся очень быстро, и для скачивания даже заходить на сайт не надо будет =)
Можно воспользоваться всякими .htaccess для защиты директории (что, кстати, тоже не кроссплатформенно, работает только под апачем, ну да фиг с этим), но это — дополнительный геморрой пользователю, нужно еще один пароль вводить.

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

Вроде вот так =)

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

deleon, кстати да, картинки ведь можно тоже в базе данных хранить. Только нагрузка на нее возрастет. Зато так просто не скачаешь.