simplyAl
Guest
Download cкрипт, чать 2. Нетривиальный контроль доступа. (+)
Download скрипт для больших файлов (от 500метров) с контролем доступа.
Задача:
Сделать контроль доступа НЕ средствами апача, а отдавать файлы именно апачем. Версия апача 2.х. Если под 2.х вообще никак не удастся сделать, пусть будет 1.х – лишь бы работало.
Как это работает:
Есть БД, в которой есть строчка
Hash | filename | file_on_hdd | time_expire | count
SCO2ld7qHiV | MyAppOrWhatever.exe | file001.ext | 1113508529 | 0
Hash – хеш, тут все понятно
Filename – имя файла, которое нужно будет выплюнуть пользователю
file_on_hdd – реальное имя фала под которым он сохранен на диске
time_expire – время в будущем до которого открыт доступ
count – кол-во запросов к файлу
Имеет запрос от юзера:
/getfile.php?hash=SCO2ld7qHiV
На стадии контроля доступа проверяем:
1) Открыт ли еще доступ к данному файлу (поле в БД time_expire)
2) Не превышено ли кол-во запросов к данному файлу? Например, в настройках скрипта указывается, что к каждому файлу можно делать макс 100 запросов, после этого доступ закрывается.
Если файл доступен, то отдаем файл file001.ext с именем MyAppOrWhatever.exe через апач.
Почему отдавать через апач, а не через ПХП путем readfile() и т.д.?
Я пробовал отдавать через ПХП, скорость на больших файлов получается в несколько раз ниже, закачка произвольно отрубается на середине, апач начинает отжирать ОЗУ соразмерно объему файла (а файлы по 500 метров).
Если скачивать обычный статический файл (т.е. когда сам апач отдает файл «напрямую»), то все работает корректно - ОЗУ не жрется, скорость высокая, докачка работает (хотя и на ПХП докачку написать не проблема).
Почему ограничивать доступ не средствами апача?
Я не нашел такого модуля к апачу, который бы проверял expire файла по времени, кол-во запросов и брал данные из БД.
Идеи:
РАЗ: Написать модуль к апачу на перле. Теоретически можно написать модуль, относительно простой, который бы при запросе к файлу проверял его доступность и редиректил бы апач (но не юзера!, юзер не должен видеть прямой ссылки на файл) на реальный файл, попутно подставляя нужное имя файла юзеру в response-header.
НО: пока не могу разобраться как заставить работать перловые модули под Апач 2.0. ХЗ как там вообще что, опыт написания модулей небольшой….
ДВА: ПХП+simlinks+htaccess(?)
Предположим, параллельно с созданием строчки в базе, еще и создаем симлинк в директории доступной через веб:
/www/get/<hash>/<filename> -> /<file_on_hdd>
Т.е. в нашем случае:
/www/get/SCO2ld7qHiV/MyAppOrWhatever.exe -> /file001.ext
Теперь каким-то образом нужно сделать так, чтобы все запросы, которые идут внутрь /www/get/*, попадали туда только если некий скрипт get.php вернет «ОК».
Т.е. юзер обращается на http://www.mysite.com/get/SCO2ld7qHiV/MyAppOrWhatever.exe
Реально же пускается скрипт get.php, который проверяет доступ и если все хорошо, то говорит апачу «ОК» (не представляю как это реализовать
) и апач отдает файл через симлинк.
В общем, такие вот у меня размышления, пока реально ничего сделать не удалось кроме раздачи файлов через ПХП путем чтения и echo контента, что не есть приемлемый вариант.
Download скрипт для больших файлов (от 500метров) с контролем доступа.
Задача:
Сделать контроль доступа НЕ средствами апача, а отдавать файлы именно апачем. Версия апача 2.х. Если под 2.х вообще никак не удастся сделать, пусть будет 1.х – лишь бы работало.
Как это работает:
Есть БД, в которой есть строчка
Hash | filename | file_on_hdd | time_expire | count
SCO2ld7qHiV | MyAppOrWhatever.exe | file001.ext | 1113508529 | 0
Hash – хеш, тут все понятно
Filename – имя файла, которое нужно будет выплюнуть пользователю
file_on_hdd – реальное имя фала под которым он сохранен на диске
time_expire – время в будущем до которого открыт доступ
count – кол-во запросов к файлу
Имеет запрос от юзера:
/getfile.php?hash=SCO2ld7qHiV
На стадии контроля доступа проверяем:
1) Открыт ли еще доступ к данному файлу (поле в БД time_expire)
2) Не превышено ли кол-во запросов к данному файлу? Например, в настройках скрипта указывается, что к каждому файлу можно делать макс 100 запросов, после этого доступ закрывается.
Если файл доступен, то отдаем файл file001.ext с именем MyAppOrWhatever.exe через апач.
Почему отдавать через апач, а не через ПХП путем readfile() и т.д.?
Я пробовал отдавать через ПХП, скорость на больших файлов получается в несколько раз ниже, закачка произвольно отрубается на середине, апач начинает отжирать ОЗУ соразмерно объему файла (а файлы по 500 метров).
Если скачивать обычный статический файл (т.е. когда сам апач отдает файл «напрямую»), то все работает корректно - ОЗУ не жрется, скорость высокая, докачка работает (хотя и на ПХП докачку написать не проблема).
Почему ограничивать доступ не средствами апача?
Я не нашел такого модуля к апачу, который бы проверял expire файла по времени, кол-во запросов и брал данные из БД.
Идеи:
РАЗ: Написать модуль к апачу на перле. Теоретически можно написать модуль, относительно простой, который бы при запросе к файлу проверял его доступность и редиректил бы апач (но не юзера!, юзер не должен видеть прямой ссылки на файл) на реальный файл, попутно подставляя нужное имя файла юзеру в response-header.
НО: пока не могу разобраться как заставить работать перловые модули под Апач 2.0. ХЗ как там вообще что, опыт написания модулей небольшой….
ДВА: ПХП+simlinks+htaccess(?)
Предположим, параллельно с созданием строчки в базе, еще и создаем симлинк в директории доступной через веб:
/www/get/<hash>/<filename> -> /<file_on_hdd>
Т.е. в нашем случае:
/www/get/SCO2ld7qHiV/MyAppOrWhatever.exe -> /file001.ext
Теперь каким-то образом нужно сделать так, чтобы все запросы, которые идут внутрь /www/get/*, попадали туда только если некий скрипт get.php вернет «ОК».
Т.е. юзер обращается на http://www.mysite.com/get/SCO2ld7qHiV/MyAppOrWhatever.exe
Реально же пускается скрипт get.php, который проверяет доступ и если все хорошо, то говорит апачу «ОК» (не представляю как это реализовать
) и апач отдает файл через симлинк.В общем, такие вот у меня размышления, пока реально ничего сделать не удалось кроме раздачи файлов через ПХП путем чтения и echo контента, что не есть приемлемый вариант.
