2013-03-15 2 views
2

У меня есть файл PDF.js, работающий на моем сервере, но я борюсь с тем, как я мог реализовать его, не подвергая свой путь к файлу (или, в идеале, переносить мои файлы за пределы веб-корня).Как я могу скрыть путь к файлу в PDF.js

например. я мог реализовать сквозную PHP, где я называю http://example.com/view?file=yyy.pdf&subdir=zzz

, а затем я мог бы использовать pdf.js, чтобы открыть файл, расположенный на скажу, http://example.com/obscure/zzz/yyy.pdf (вместо вызова http://example.com/viewer?file=http://example.com/obscure/zzz/yyy.pdf)

ИЛИ еще лучше, файл за пределами webfoot по адресу: /absolute/path/zzz/yyy.pdf

+1

FYI: [example.com] (http://example.com) есть по причине. –

+0

Уже был дан ответ: http://stackoverflow.com/questions/10834196/secure-files-for-download –

+0

Да! Это открывает файл, спасибо. Но я не уверен, как это делает PDF.js. – littlered

ответ

0

NB 26 марта 2013 г. - Извиняюсь, поскольку мне придется отказаться от первоначального ответа.

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

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

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

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

SSL был бы требованием для любого устройства с высокой степенью защиты, поскольку в противном случае можно было бы отслеживать сетевое соединение и повторно использовать ключ в течение таймаута. Система аутентификации, которая запускает PDF.js, должна будет координировать работу с шлюзом документов для ключа, который PDF.js будет использовать для перезвона и получения доступа. Это можно сделать с помощью обмена сообщениями на сервере, которые может выполнить база данных CMS.

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

Вот смысл оригинальной порочной идеи, для справки:

Там оказалось легко, но теперь видели ложный ответ для защиты файлов, с помощью .htaccess условия, чтобы только ваша локально поставляемых pdf.js разрешает доступ к каталогу, содержащему pdf-файлы. Этот каталог должен находиться на веб-сайте, потому что pdf.js обращается к веб-пространству, а не к файловому пространству. Вот форма и реакции, которые вы можете настроить для вашего URL и pdf.js местоположение:

Options -Indexes 
RewriteEngine On 
RewriteCond %{HTTP_REFERER} !^(http|https)://(www.)?yourdomain\.com/yourfolder/s/pdf\.js$ 
RewriteRule .* - [F]