cotonti.com : Закрытие файлов https://www.cotonti.com Neueste Themenbeiträge Cotonti en Sat, 31 Jan 2026 08:41:58 -0000 Trustmaster Mi, 07 Apr 2010 16:57:18 -0000 jcrush Mi, 07 Apr 2010 16:25:28 -0000 Aristei Я так понимаю в версии 0.6.7 при использовании ссылки вида http://www.site.ru/page.php?id=5&a=dl загрузка файла не начнется если пользователь не находится на странице page.php?id=5. Т.е. пользователь будет перенаправлен на страницу page.php?id=5 и только от туда при клике загрузить «Имя файла» будет происходить загрузка?

Странно работает ссылка вида http://www.site.ru/page.php?id=5&a=dl например с главной сайта при клике на нее первый раз перенаправляет на страницу, возвращаясь затем обратно на главную и снова кликая по этой ссылке начинается скачка файла.]]>
Mi, 07 Apr 2010 12:09:31 -0000
dervan # Ratibor : Вот именно что пользователь щелкнул по файлу, а мы его редиректим не поими куда :-)
Лично меня это бесит.
Если точнее, мы посетителя не редиректим. Посетитель кликает ссылку, по которой он штатно переходит на страницу загрузки файла - это не редирект. Эту ссылку можно соответсвенно оформить - поставить слева иконку download, чтобы он знал, чего ожидать, тогда и раздражать поменьше будет. Да и вообще, переход для загрузки файла на специальную страницу - это сейчас широко распространённая практика.

А страница эта - мера вынужденная. Для скрипта, отправляющего файл ( у меня в примерах он звался indirect.php ), необходимо сформировать в сесии данные, подтверждающие, что был заход на страницу зайта. Формировать в сесии эти данные надо только при генерировании хостом той страницы, где находится ссылка на скрипт indirect.php с ключом файла. Например, запрос AJAX на формирование таких данных при клике по ссылке в данном случае не подойдёт - такой запрос не является признаком того, что файл загружается со своей, а не с чужой страницы. Но отказываться от кеширования всех страниц, где могут быть ссылки на закрытые файлы, нельзя, а при обращении к кешированной странице ничего сформировать невозможно. Поэтому необходима такая дополнительная страница download.php, которая не будет кешироваться и при обращении к которой в сесии будут сформированы данные для indirect.php.


# Ratibor : Он и так уже попал не туда куда собирался, кликнув на левом сайте по ссылке на файл на твоем сайте :-)
Дак зачем ему еще и выдавать сообщение об ошибке, лучше уж направить его туда куда надо.
Предлагаю разложить по полочкам, чтобы не было путаницы. :)

Задача: предотвратить скачивание закрытых файлов по прямым ссылкам.
Решение: ликвидировать прямые ссылки на закрытые файлы, запретив доступ по HTTP к этим файлам.
Исполнение: поместить закрытые файлы в специальный каталог, в котором должен находиться блокирующий .htaccess:
<Files ~ "*">
order allow,deny
deny from all
</Files>

Редирект в корневом .htaccess - это отдельная песня. :) Он может быть или не быть, хост может не поддерживать mod_rewrite, админ может промахнуться, прописывая редирект в корневом .htaccess - но всё это неважно, если в каталоге с закрытыми файлами лежит блокирующий .htaccess.


# Ratibor : Можно к примеру создать страницу для этих целей, там написать типа сорри, но на этом сайте стоит защита от левых сайтов, так что еще раз приносим свои извинения и если хотите скачать данный файл, вам тудато. И нормальный человек поймет что на тот сайт больше заходить не надо, т.к. тот сайт жалкая копия.
В общем в любом случае пользователя лучше грамотно перенаправить туда куда надо,
причем средствами мод реврайта это получится более комфортно для всех.
Теперь про то, как перенаправить пользователя с левых ссылок. :)

Для начала посмотрим цепочку к файлу на своём сайте.

Положим для примера, что у нас есть такой специальный bbcode для закрытых файлов:
[hfile=indirect/test.zip name=test.zip /]

При создании кешированной страницы парсер bbcode вычисляет хэш-ключ и формирует ссылку на страницу загрузки с этим ключом в параметре:
$filekey = md5('indirect/test.zip');
$body .= "<a href=https://www.cotonti.com/\"download.php?key=$filekey\">test.zip</a>";

Скрипт страницы загрузки download.php берёт по этому ключу из базы путь к файлу $fspec ( возможно, ещё берёт описание файла, его рейтинг и т.п. ), затем создаёт страницу со ссылкой на скрипт indirect.php ( тот, что будет отправлять файл, в параметре этой ссылки - тот же самый хэш-ключ ), и формирует в сессии данные для этого скрипта indirect.php:
$filekey = sed_import('key', 'G', 'ALP');
// считывание из базы $fspec по $filekey
$body .= "<a href=https://www.cotonti.com/\"indirect.php?key=$filekey\">" . basename($fspec) . "</a>";
$_SESSION['indirect'][$filekey]['fspec'] = $fspec;


Скрипт indirect.php с ключом $filekey лезет в сессию за $fspec. Если он там есть, то отправляет файл. Если нет, то значит посетитель пришёл по левой ссылке, тогда indirect.php сохраняет REFERER в сессии ( $_SESSION['indirect'][$filekey]['referer'] ) и делает редирект на download.php?key=$filekey. Скрипт download.php смотрит в сессию - ага, там сохранён REFERER, анализирует его, если он левый - говорит посетителю пару ласковых про этот REFERER :) и удаляет REFERER из сессии, а посетитель может скачать файл по ссылке на этой странице загрузки файла.

В данном случае .htaccess для редиректа не нужен.

Остался случай с прямой ссылкой на закрытый файл, например:
hrttp://www.mysite.ru/indirect/test.zip
Возникает вопрос: как была получена прямая ссылка? В параметрах её не было. В сеть она не передавалась, так что подсмотреть её протокольным анализатором было невозможно. Ответ такой: ссылка была получена взломщиком из хэша md5. Сей господин обойдётся без редиректа на страницу загрузки файла, ему будет полезнее полюбоваться на сообщение об ошибке. :)

Вывод: для закрытых файлов редирект в корневом .htaccess не нужен.


P.S.
И ещё раз про REFERER. ( Правда - то, что повторено трижды. (c) :) )

Система распознавания "свой-чужой" на основе REFERER - это несерьёзно. Нет никакого смысла нагружать хост скриптами, пересылающими файлы, если при этом допустимость ссылок контролируется по REFERER. IMHO тогда уж лучше обойтись без излишних сложностей, средствами mod_rewrite в .htaccess:
# anti hotlinking
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?mysite\.com/ [NC]
RewriteCond %{HTTP_REFERER} !babelfish [NC] # babelfish.yahoo.com
RewriteCond %{HTTP_REFERER} !/translate_c\? [NC] # translate.google.com
RewriteCond %{HTTP_REFERER} !^http://(www\.)?translate\.ru/ [NC] # translate.ru
RewriteRule !^img/mysite88x31\.gif$ - [C,NC]
RewriteRule !^img/hotlinking\.gif$ - [C,NC]
RewriteRule \.(jpe?g|gif|png|bmp|avi|mpe?g|vob|flv|swf|mp3|7z|gz|rar|zip|txt|pdf|ttf)$ http://mysite.com/img/hotlinking.gif [L,NC]
Здесь файлы отсылаются по запросам с такими REFERER: пустой, свой сайт mysite.com, сайты онлайн-переводчиков. Баннер img/mysite88x31.gif отсылается по любым REFERER. В остальных случаях вместо запрошенных файлов отсылается img/hotlinking.gif.]]>
Fr, 20 Feb 2009 08:57:15 -0000
Ratibor # dervan : Да я не про безопасность говорил, а про то, что HTTP-протокол передачи файла в PEAR HTTP_Download реализован лучше, обстоятельнее, чем в классе NDL. А класс NDL нужен только для передачи файла по HTTP-протоколу.
Да я не против :-)
Раз PEAR HTTP_Download лучше дак и спорить не о чем :-)

# dervan : Весьма распространённая практика. Например, сходи на Sourceforge, Cnet, и т.д.. А страницу эту можно сделать полезной - подробная информация о файле, число закачек/рейтинг и т.п.

IMHO лучше выдать чёткое сообщение о конкретной ошибке, а не редиректить посетителя не пойми куда, куда он не собирался. :)

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

Теперь собственно об этом:
# dervan : IMHO лучше выдать чёткое сообщение о конкретной ошибке, а не редиректить посетителя не пойми куда, куда он не собирался. :)
Он и так уже попал не туда куда собирался, кликнув на левом сайте по ссылке на файл на твоем сайте :-)
Дак зачем ему еще и выдавать сообщение об ошибке, лучше уж направить его туда куда надо.
Можно к примеру создать страницу для этих целей, там написать типа сорри, но на этом сайте стоит защита от левых сайтов, так что еще раз приносим свои извинения и если хотите скачать данный файл, вам тудато. И нормальный человек поймет что на тот сайт больше заходить не надо, т.к. тот сайт жалкая копия.
В общем в любом случае пользователя лучше грамотно перенаправить туда куда надо,
причем средствами мод реврайта это получится более комфортно для всех.]]>
Do, 19 Feb 2009 18:51:07 -0000
dervan # Ratibor : Цель то не в том чтоб создать супер защищенное хранилище файлов,
а в том чтоб элементарно защититься от разного рода сателлитов и клонов
А зачем тогда городить огород с передачей файла скриптом? :) Элементарную защиту с использованием REFERER можно сделать в .htaccess средствами mod_rewrite.

# Ratibor : dervan
Если PEAR HTTP_Download позволяет это реализовать и в нем нет дыр в безопасности,
то конечно лучше использовать его,
тем более у него лицензия BSD и ничего даже переделывать не придется.
Да я не про безопасность говорил, а про то, что HTTP-протокол передачи файла в PEAR HTTP_Download реализован лучше, обстоятельнее, чем в классе NDL. А класс NDL нужен только для передачи файла по HTTP-протоколу.

# Ratibor : По поводу кэшированных страниц.
Насколько я понял в описанной тобой реализации получается юзер щелкает по ссылке
и его перебрасывает на download.php, а оттуда он собственно и скачивает файл.
Если это так, то это не приемлемо, не должно быть никаких редиректов.
Весьма распространённая практика. Например, сходи на Sourceforge, Cnet, и т.д.. А страницу эту можно сделать полезной - подробная информация о файле, число закачек/рейтинг и т.п.

# Ratibor : ИМХО лучше использовать mod_rewrite и перекинуть пользователя на нужную тебе страницу,
а не выводить сообщение об ошибке или что доступ запрещен.
IMHO лучше выдать чёткое сообщение о конкретной ошибке, а не редиректить посетителя не пойми куда, куда он не собирался. :)]]>
Do, 19 Feb 2009 18:18:26 -0000
Ratibor dervan
Цель то не в том чтоб создать супер защищенное хранилище файлов,
а в том чтоб элементарно защититься от разного рода сателлитов и клонов.
Главное чтоб не было дыр в безопасности.

Если PEAR HTTP_Download позволяет это реализовать и в нем нет дыр в безопасности,
то конечно лучше использовать его,
тем более у него лицензия BSD и ничего даже переделывать не придется.

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

# dervan : 1.
Этот пункт реализован, но усложнённо - применение mod_rewrite здесь избыточно. Можно реализовать проще: завести каталог для закрытых файлов, например indirect, и положить в него блокирующий .htaccess:
ИМХО лучше использовать mod_rewrite и перекинуть пользователя на нужную тебе страницу,
а не выводить сообщение об ошибке или что доступ запрещен.]]>
Do, 19 Feb 2009 15:21:45 -0000
dervan Ratibor, разбирался я как-то с этим вопросом.

Про реализацию на основе ndl-2003-05-19_10.zip. Подход верный, но контроль допустимости ссылки на закрытый файл сделан через REFERER - это неправильно, из-за этого неизбежны дыры.

Попытки ограничить доступ к файлам проверкой REFERER ненадёжны и годятся разве что для простого anti-hotlinking'а, который можно сделать в .htaccess средствами mod_rewrite. Во-первых, REFERER легко подделать. Во-вторых, HTTP-запрос с пустым REFERER нельзя отвергать, но если его не отвергать - опять же получится дыра.

Пример подделки REFERER.
В ReGet Deluxe Personal добавляем закачку: на закладке "Общие" в поле "URL:" вбиваем косвенную ссылку "http://www.my_site.ru/my_files/examples/example02/get.php?file=test", на закладке "HTTP" в поле "Ссылка" вбиваем её же. После этого файл будет успешно скачан, несмотря на отсутствие прямой ссылки на него.

Пример с пустым REFERER.
Браузер посетителя - Opera 9 со снятым чекбоксом: Tools -> Preferences... -> Advanced -> Network -> Send referrer information (Инструменты -> Настройки... -> Дополнительно -> Сеть -> Отправлять данные о ссылающейся странице). Браузер не будет отправлять REFERER, и посетитель не сможет скачивать файлы, хотя и будет идти по ссылкам со страницы http://www.my_site.ru/my_files/examples/examples.html.

Реализация надёжного упрятывания файлов.

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

2.
Следствие из п.1: отправку файла по запросу HTTP должен делать скрипт, работающий аналогично HTTP-серверу - скрипт, считывающий файл с диска и отправляющий его в сеть в соответствии с протоколом HTTP.

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

Что сделано в приведённой тобой реализации.

1.
Этот пункт реализован, но усложнённо - применение mod_rewrite здесь избыточно. Можно реализовать проще: завести каталог для закрытых файлов, например indirect, и положить в него блокирующий .htaccess:
<Files ~ "*">
order allow,deny
deny from all
</Files>

2.
Этот пункт тоже реализован. Отправку файла по протоколу HTTP делает класс NDL (файл ndl.class.php). Посмотрел, как формируются HTTP-заголовки, видно что реализация упрощённая - например, не формируется рекомендованный заголовок ETag. Может, и будет нормально работать, но IMHO лучше прикрутить PEAR HTTP_Download.

3.
Привязки к заходу на страницу нет вообще. Сделана проверка REFERER классом ANDL (файл andl.class.php), но такая проверка - дырявая.

Вместо этого можно сделать реализацию через сессию.

1) Реализация при отключенном кешировании страниц.

Путь к закрытому файлу содержится на нераспарсенной странице в специальном bbcode, например с префиксом @:
[url=@indirect/test.zip]test.zip[/url]

При заходе на страницу парсер bbcode получает из пути ключ. С этим ключом парсер создаёт переменные в сессии:
$sesskey = md5('indirect/test.zip');
$_SESSION['indirect'][$sesskey]['fspec'] = 'indirect/test.zip';
$_SESSION['indirect'][$sesskey]['uid'] = $usr['id'];
и помещает на страницу ссылку на скрипт indirect.php, отправляющий файл:
$body .= "<a href=https://www.cotonti.com/\"indirect.php?$sesskey\">test.zip</a>";

Действия скрипта indirect.php:
< ? php
if (!isset($_REQUEST[session_name()]))
{
	exit; // невозможно возобновить сессию
}
session_start();
if (empty($_SERVER['QUERY_STRING'])
	|| !isset($_SESSION['indirect'][$_SERVER['QUERY_STRING']]) // данные не сформированы, не было захода на страницу со ссылкой
	|| !file_exists($fspec = $_SESSION['indirect'][$_SERVER['QUERY_STRING']]['fspec'])
	|| $_SESSION['indirect'][$_SERVER['QUERY_STRING']]['uid'] < 1 // закачка разрешена только зарегестрированным посетителям
	)
{
	exit;
}
// отправка файла $fspec - PEAR HTTP_Download, либо класс NDL
...

2) Реализация при включенном кешировании страниц.

Надо ввести специальную страницу download.php, которая никогда не кешируется. Ссылки с кешированных страниц будут идти на неё, и при заходе на эту страницу download.php в сессии будут создаваться переменные для indirect.php, а на самой странице download.php будет помещена ссылка на скрипт indirect.php, отправляющий файл:
$body .= "<a href=https://www.cotonti.com/\"indirect.php?$sesskey\">test.zip</a>";
]]>
Do, 19 Feb 2009 11:33:58 -0000
Ratibor
Работает все на ура.
Берем этот скрипт.
Создаем к примеру в корне папку my_files
распаковываем скрипт в эту папку.
Там вроде ошибка в ndl.class.php в 172 строке.
удаляем эту строку, т.к. она там дважды прописана.
далее в браузере вводим http://www.my_site.ru/my_files/examples/examples.html
щелкаем по ссылкам чтобы убедиться что прямые ссылки не выдаются.
далее правим config.inc.php
меняем
$allowToAll	= true;
на
$allowToAll	= false;
и ниже вписываем
$allowedHosts = array
(
	"www.my_site.ru"
);

Идем на http://www.my_site.ru/my_files/examples/examples.html
щелкаем по файлам и убеждаемся что с вашего сайта файлы грузятся нормально.
Теперь копируем в буфер ссылку на файл и вводим в отдельном окне.
Получаем фигвам, что и требовалось.
Но это только пол дела, осталось защититься от прямых ссылок.
Ну это уже проще простого :-)
В .htaccess прописываем:
Options FollowSymLinks -Indexes
RewriteEngine On
RewriteBase "/"
RewriteRule ^(my_files)/(examples)/(data)/(.*)$ index.php [NC,NE,L] 

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

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

Вот теперь все это прикрутить бы к движку :-)]]>
Do, 19 Feb 2009 03:09:58 -0000
motor2hg ]]> Do, 19 Feb 2009 02:38:29 -0000 Ratibor # motor2hg : Странно у меня переход на сайт! Понял у тебя Опера, она почему-то начинает закачку, Firefox переходит на сайт В Opera и IE не переходит, а сразу начинает закаку.
Я же сказал - это понты для приезжих. :-)

Проверил также в FireFox, тоже не переходит на твой сайт, а начинается загрузка файла.
Правда FireFox у меня под фрей, виндового нет.]]>
Do, 19 Feb 2009 01:03:16 -0000
motor2hg Do, 19 Feb 2009 00:47:30 -0000 Ratibor # motor2hg : Ну, так ты же знаешь архитектуру движка, а тот кто будет копировать контент твоего сайта, ему надо быстро и так глубоко заморачиваться он не станет
Да причем здесь знание архитектуры ? Не нужны никакие знания архитектуры.
Даже если ты каким то чудом защитишься от скачивания по таким ссылкам:
http://www.nikiza.ru/page.php?id=181&a=dl
Достаточно зайти на сайт и нажать на скачивание и сразу получаешь прямую ссылку.
Так что без защиты от прямых ссылок - это деньги на ветер.

И еще раз повторюсь, ты написал что если я с этого сайта кликну по этой ссылке:
http://www.nikiza.ru/page.php?id=181&a=dl
то я попаду на твой сайт.
Нифига я туда не попадаю, а начинается скачивание файла.]]>
Do, 19 Feb 2009 00:40:23 -0000
motor2hg Do, 19 Feb 2009 00:33:17 -0000 Ratibor # motor2hg : Это ссылка на файл с моего сайта, так как cotonti.com не включен в список сайтов которым разрешено на прямую качать с моего сервера то кликнув по ссылке юзер попадёт на мой сайт.
Да ну ? Блажен верующий :-)
Чтото я не попадаю на твой сайт по этой ссылке, а сразу начинается скачивание файла :-)
А уж тем более нет защиты от прямой ссылки:
http://www.nikiza.ru/datas/users/1-anvirrus.rar

Еще раз повторю, плагин тефры - это понты для приезжих,
он не защищает ничего и ни от кого.]]>
Do, 19 Feb 2009 00:13:01 -0000
motor2hg Ты создал сайт, наполнил инфой и какимито файлами.
Я беру и тупо копирую его, и всавляю прямые ссылки на файлы находящиеся на твоем сайте.
Гугл при индексации моего сайта видит вот это:
http://www.mysite.com/page.php?id=55&a=dl
т.е. тебе от этого никакой пользы.
Я доволен, т.к. не надо напрягаться по поводу размещения файлов,
мои юзеры тоже, а тебе только головняк в виде увеличенного трафика.

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

Именно эту задачу и выполняет simple-leech-protection-2

http://www.nikiza.ru/page.php?id=181&a=dl

Это ссылка на файл с моего сайта, так как cotonti.com не включен в список сайтов которым разрешено на прямую качать с моего сервера то кликнув по ссылке юзер попадёт на мой сайт.]]>
Mi, 18 Feb 2009 23:58:26 -0000
Ratibor # motor2hg : Эту защиту уже сделал Тефра.
Этот скрипт ничего ни от кого не защищает.]]>
Mi, 18 Feb 2009 23:40:02 -0000
motor2hg
http://www.t3-design.com/simple-leech-protection-2/]]>
Mi, 18 Feb 2009 23:21:08 -0000
Ratibor # Sergeich : Я просто не понимаю зачем всё это? Если речь идёт о какой то конфиденциальной очень ценной информации, то высылайте её почтой своим клиентам.
Нет, речь не идет о какой то конфиденциальности,
речь идет об защите файлов от незарегистрированных пользователей.
Даже не то чтобы от зарегистрированных, а чтобы файл можно было скачать только находясь на сайте.
В общем об элементарной защите от всяких сателлитов и клонов.

Объясняю на пальцах:

Ты создал сайт, наполнил инфой и какимито файлами.
Я беру и тупо копирую его, и всавляю прямые ссылки на файлы находящиеся на твоем сайте.
Гугл при индексации моего сайта видит вот это:
http://www.mysite.com/page.php?id=55&a=dl
т.е. тебе от этого никакой пользы.
Я доволен, т.к. не надо напрягаться по поводу размещения файлов,
мои юзеры тоже, а тебе только головняк в виде увеличенного трафика.

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

Вот тут нашел кое что.

Там чтобы скачать, надо зарегистрироваться.
На всякий случай выкладываю тут:
http://www.cotonti.com/datas/users/ndl-2003-05-19_10.zip

Вот еще какой то antileech:
http://www.cotonti.com/datas/users/1603_10.zip]]>
Mi, 18 Feb 2009 22:43:05 -0000
Sergeich Mi, 18 Feb 2009 22:13:40 -0000 Dayver # Sergeich : Если файл может скачать 1 человек, то его могут скачать все. Смысла во всех этих ухищрениях - ноль. В крайний случай никто не отменял рапиды всякие.
Не факт.....пускай один чел скачал файл(и он запомнил\записал прямую ссылку на него) и дал ссылку другому.......а если файл после этого переименован(например через час после того как его запросил\скачал первый чел)? то развив эту тему его можно будет скачать тооолько по ссылке вида http://www.cotonti.com/page.php?id=55&a=dl....но считаю что вопрос из ряда фенечек которыми сейчас не стоит заниматся]]>
Mi, 18 Feb 2009 20:26:07 -0000
Ratibor # Sergeich : Если файл может скачать 1 человек, то его могут скачать все. Неправильно.
Если файл может скачать 1 человек, то его могут скачать все, но только находясь на сайте.
Нужно чтобы была защита от прямых ссылок.

Возьмем к примеру вот эту страницу:
http://www.cotonti.com/downloads/plugins/general/FCKeditor
там внизу есть ссылка для скачивания:
http://www.cotonti.com/page.php?id=55&a=dl
Также можно ввести:
http://www.cotonti.com/datas/users/fckeditor_10.zip

И скачается один и тот же файл, что не есть гут.

Нужна защита, если человек введет в браузере вот такое:
http://www.cotonti.com/datas/users/tags_10.zip
то должен получить фигвам :-)

В общем можно было скачать файл только по этой ссылке:
http://www.cotonti.com/page.php?id=55&a=dl
да и то если только юзер зашел под своим именем и в данный момент находится на сайте.
В общем чтоб никто при всем желании не смог узнать прямой ссылки на файл,
ну или хотябы по прямой ссылке файлы не отдавались.]]>
Mi, 18 Feb 2009 19:55:36 -0000
Sergeich Mi, 18 Feb 2009 19:38:56 -0000 Ratibor # Trustmaster : Да, нужно реализовать привязку сессии антилича к сессии Seditio с проверкой прав доступа. Мы это с diablo обсуждали, вчера кажется. Нужно-то оно нужно, но сделать пока некому. Планируется это или всеже пока заглохло ?]]> Mi, 18 Feb 2009 19:19:01 -0000 Trustmaster diablo обсуждали, вчера кажется. Нужно-то оно нужно, но сделать пока некому. Я, как закончу с неотложными делами и организационными вопросами, в первую очередь займусь проектом "The Royal BugHunt". Kilandor'у сейчас работы тоже хватает. Остальные пока в сторонке стоят, за что-либо более-менее серьёзное браться боятся, либо заняты.]]> Mi, 06 Aug 2008 16:49:06 -0000 Ratibor Trustmaster
Плагины эти легко обходятся, файл в оконцовке можно скачать.
А вот про скрипт незнаю.

Нужно чтоб закрытый файл никто впринципе не смог скачать, окромя тех пользователей которым разрешон доступ.
Причем они могут скачать, только тогда когда зайдут на сайт под своим именем.]]>
Mi, 06 Aug 2008 16:08:08 -0000
Trustmaster Mi, 06 Aug 2008 16:03:03 -0000 Ratibor
Как закрыть файлы от посторонних ?
Тэг хайд конечно хорошо, но.....
К примеру я закрываю тэгом хайд ссылку на какой либо файл.
Скрываю от гостей и обычных пользователей.
Могут увидеть только привелигированные пользователи.
Но, ничего не мешает, какому-нибудь привелигированному пользователю опубликовать прямую ссылку на файл на каком-нибудь другом сайте, что не есть гуд :(

И еще для кучи по группам.
Вроде под дле видел интересный модуль, к примеру на сайте делаешь закрытую облать,
так вот этот можуль генерирует ключи для юзеров, ключь имеет временное ограничение,
ты даешь ключь юзеру, он его вводит у себя в профиле и получает на время действие ключа доступ к закрытой части.
Причем ключь подходит только тому юзеру, для кого он генерировался.]]>
Mi, 06 Aug 2008 15:59:52 -0000