в локальной сети есть платный видео сервер, через веб интерфейс можно найти нужный фильм в базе и скачать его, закачка осуществляется через ftp. ftp доступен только c ip заплативших клиентов.
как лучше организовать сервер что бы нельзя было зайти на фтп в обход веб интерфейса, даже заплатившим пользователям, может вообще сделать не через фтп? и еще сделать соответствие ip mac адреса что бы все могли просматривать веб но только оплатившие могли скачивать(нельзя поменять ip и скачать)?
система: redhat9 proftpd 1.3.0rc1 apache 2
Реализовать данную схему лучше следующим образом:
1. Прикрутить систему авторизации к веб интерфейсу.
2. Выдавать файлы через специальный скрипт, который будет проверять авторизованность клиента (например сессии).На тему фтп конечно тоже можно пофантазировать, но имхо данная схема самая простая.
>Реализовать данную схему лучше следующим образом:
>1. Прикрутить систему авторизации к веб интерфейсу.
>2. Выдавать файлы через специальный скрипт, который будет проверять авторизованность клиента (например
>сессии).
>
>На тему фтп конечно тоже можно пофантазировать, но имхо данная схема самая
>простая.интересует вопрос где и как разместить сами файлы, что бы возможность скачать была только у зарегистрированных пользователей?
>интересует вопрос где и как разместить сами файлы, что бы возможность скачать
>была только у зарегистрированных пользователей?Элементарно! =) Файлы хранить вдали от хттп и выдавать их в браузер юзеру через скрипт, только нада в заголовке указывать майм тайп и реальное название файла!!! Причём фалы можно хранить не только в фс но и в бд, но это уже кому как больше нравится =)
>>интересует вопрос где и как разместить сами файлы, что бы возможность скачать
>>была только у зарегистрированных пользователей?
>
>Элементарно! =) Файлы хранить вдали от хттп и выдавать их в браузер
>юзеру через скрипт, только нада в заголовке указывать майм тайп и
>реальное название файла!!! Причём фалы можно хранить не только в фс
>но и в бд, но это уже кому как больше нравится
>=)
Хранить большие файлы в БД неверно. Лучше хранить линки на файлы.
>Реализовать данную схему лучше следующим образом:
>1. Прикрутить систему авторизации к веб интерфейсу.
>2. Выдавать файлы через специальный скрипт, который будет проверять авторизованность клиента (например
>сессии).
>
>На тему фтп конечно тоже можно пофантазировать, но имхо данная схема самая
>простая.
Можно так:
1. Файлы лежат в недоступном по http месте.
2. При выборе файла пользователем создается временная директория с нечитаемым названием, туда генерируется .htaccess со всеми возможными ограничителями ( по Ip, User-Ageth, ещё_что-то )
и туда же кладется сим-линк на файл
3. диры чистятся через X минут после генерирования/последнего обращения
>Можно так:
>1. Файлы лежат в недоступном по http месте.
>2. При выборе файла пользователем создается временная директория с нечитаемым названием, туда
>генерируется .htaccess со всеми возможными ограничителями ( по Ip, User-Ageth, ещё_что-то
>)
>и туда же кладется сим-линк на файл
>3. диры чистятся через X минут после генерирования/последнего обращения
Интересно, как апач узнает, что пользователь выкачал файло, а?
Может быть просто файл скриптом отдавать?
никак.
но отдавать большие файлы через скрипт - накладно,
а так их можно отдавать каим-нибуть "легким" веб-сервером вроде nginx
>никак.
>но отдавать большие файлы через скрипт - накладно,
>а так их можно отдавать каим-нибуть "легким" веб-сервером вроде nginxИ в чем же "накладность" отдачи?
и чем Апач хуже чем nginx
наример память
одна копия apache+mod_php4 = 10-16Mb в памяти
50 одновременных клиентов = 500-800 Mb
а с учетом того, что фалы большие и соответственно предаются относительно долго, то такая ситуция вполне возможна.
>наример память
>одна копия apache+mod_php4 = 10-16Mb в памяти
>50 одновременных клиентов = 500-800 Mb
>а с учетом того, что фалы большие и соответственно предаются относительно долго,
>то такая ситуция вполне возможна.
Гиг оперативки стало для сервера - минимум.
Не вижу сложностей.
Здесь узкое место уже будет канал.