Форум PHP

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

мало че понятно,но может помочь обработка через ошибку 404
в 404.php будет лежать логика

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

мне вот, честно, интересно как поисковики будут индексировать страницы?
тем не менее предложу свой вариант.
Предположим у нас три файла (1.rar, 2.rar, 3.rar). Если к примеру передавать id={1...10} - то будет доступен такой-то файл(1.rar), id={11...20} - то будет доступен такой-то файл(2.rar), ну и так далее.
Поэтому получается ставится каждому файлу в соответсвие некий интервал.
Думаю идея понятна))

----
Regards, Max Vasin.

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

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

ид __реальный+путь+к+файлу__хеш__юзер+которому+дали+файл__время+"дачи"+файла

при "даче" файла записываем в бд всю инфу.

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

При заходе на наш скрипт вида file.php?hash=ggaf7678adfusdfysiudf берем строку из бд с данным хешом(если такой нет - выводим собалезнования), сравниваем юзера с тем кто записан в бд и в случае удачи делаем редирект на на "реальный путь к файлу" который дан в бд, в случае не удачи прощаемся с юзером и взрываем ему монитор.

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

вот..

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

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

Если крон будет запускать страницу раз в 5 минут, то ничего серверу не будет. Эффект такой, что просто как-будто к вам заходит человек 1 раз в пять минут, а это очень мало для того, чтобы повесить сервер :) Темболее затраты процессора на работу самого крона минимальны, почти не ощутимы.
Автоматического обновления бд, чтобы удалять записи нет. Можно сделать только так: в начале основного скрипта поместить запрос к бд, который будет удалять записи, которые просрочены.
Я не хотел мучиться с кроном, и сделал второй вариант - работает логично. Тоесть он срабатывает, когда человек обновляет страницу сайта, что не даёт ему скачать что-то после даного ему положенного срока, т.к. при выдачи ему страницы, сначала проверяется бд на старые линки и елси они есть, то всё удаляется, и только после этого выдаётся уже нужный контент.

Тогда уж проще пользоваться кроном. Вот представьте что на сайте 500,000 уникальных пользователей и перед закачкой каждого файла будет идти проверка на просроченность.
Я бы поставил на крон и запускал бы каждые 3-4 мин. Ничего страшного если юзер попадет в эти 3-4 минуты и времени скачать файл у него будет чуток больше.
вот...

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

Я бы и при 1000 юзерах поставил на крон, кто знает как быстро твой проект наберет популярность, а потом влом будет все переделывать. при 1000 можно и каждую минуту скрипт запускать)

Ну если проект начнёт развиваться, то на порах радости можно будет и крон поставить :))

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

Несколько уточняющих вопросов по постановке задачи:
1) Ваши пользователи авторизируются при входе?
2) Установлен ли лимит времени на доступность к файлу для каждого пользователя или он един для всех?
При ответах на вопросы:
1) да, тогда в таблице базы либо (в файле) "статистике посещений" для каждого пользователя фиксируйте время "первого доступа" и играйтесть в лимиты времени (дам - не дам).
При этом ответ на 2) вопрос - это разновидность логики. Динамически (по входу) добавляйте, модифицируйте строки в "статистике посещений", сразу же можно и чистить явно "старые" строки. Про CRON забудьте - метод "слепой секритарши переодически прощупывающей ящики входной корреспонденции", - ДУРНАЯ ПРАКТИКА. CRON-ы не для этих целей.

Сложнее если пользователи не авторизуются, то здесь проблема аутентификации (IP м. б. динамическим, КУКИ подделываются, СЕССИИ не проходят).

Я делаю так, что сами файлы с контентом лежат в папке, недоступной извне. А юзеру формирую для скачивания файл с левым путем и вставляю в это файл контент динамически.

header("Content-type: application/octet-stream");    header("Content-Disposition: inline; filename=tovar.rar");    readfile($spath."/".$pfile."/$fout");

Комментарий: зарегенный пользователь запрашивает какой то файл, я ему отдаю файл, который всегда называется "tovar.rar",
путь $path/$pfile/ задан в конфигураторе и извне недоступен.

Т.е. у меня юзер вседа видит путь /out.php/имя_файла, а получает то, что я ему определю. Незарегенный юзер до этого места не доходит.
Это упрощенно в двух словах.

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