Всем привет!

Сейчас меня конечно опять начнут все пинать, но может что и посоветуют)
Вообщем дело такое. Веб приложение, на странице встроенный pdf viewer (pdf.js). Этот pdf viewer отображает pdf файлы, которые он получает от сервера (сервлет). Так вот, сервлет мапится на адрес 127.0.0.1:8080/application/pdfservlet
По нему pdf viewer и получает pdf файл. Так вот, пользователь может пойти напрямую по этому адресу в браузере, pdf откроется в нативном окне и так пользователь сможет скачать этот pdf файл. Что не желательно.

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

НО! Я хочу использовать Ranged Requests, т.е. чтобы pdf viewer отправлял на сервер не один запрос, а много chunk запросов - это нужно для быстроты отображения (pdf viewer начнет отображать pdf файл еще до его полной загрузки - запрашивает файл по частям несколькими запросами, сколько запросов слать и когда - решает сам pdf viewer, Пролистал пользователь сразу на сотую страницу, pdf viewer запросит эту сотую страницу у сервлета первым делом, а потом уже остальное будет дозагружать).
Так получается, что решение с токеном не подходит, так как запросов pdf viewer теперь может послать хоть 100, а не один.

Вот что пришло в голову. Пусть сервер не выдает pdf viewer одноразовый токен, а пусть научит его геренировать столько валидных одноразовых токенов, сколько надо, т.е. снабдит его неким "рецептом" по генерации токенов. И pdf viewer будет отправлять по новому токену с каждым chunk запросом к сервлету. А сервлет будет проверять токены на валидность: так так, такой-то токен, да, очень похоже что он валидный, и сгенерирован по "рецепту" который я давече дал pdf viewer. Ну и каждый токен помечает как использованный, чтобы никто повторно его не использовал. Т.е. таким образом я пытаюсь добиться того, чтобы сервлет смог распознать, что запросы идут от моего pdf viewer.
Это все очень похоже на подпись, только как бы одноразовую. Что скажете, есть какие-нибудь идеи? Все не так?

Ну получается, что токен инвалидируется только когда все части файла будут считаны с сервера. А пока не весь файл покрыт - токен остается валидным. Ну и получается, если файл большой, viewer может его читать какое-то время. И все это время токен валиден. Пользователь взял этот токен (F12, Network, допустим), пошел напрямую в сервлет, использовал токен и получил быренько весь файл.
А моя идея для каждого chunk запроса использовать уникальный одноразовый токен.

F12 - network, че там узнавать-то, я сам все время так делаю, когда хочу с сайта скачать что-нибудь там где "нельзя" из коробки

Т.е. другими словами, пусть токен будет UUID. И я определяю некоторое подмножество всех возможных UUID как "валидные токены".
И pdf viewer пусть смело берет токены из этого подмножества и использует их с каждым chunk запросом. И причем это подмножество пусть меняется с каждым новым отображением страницы (с каждым F5 - новый алгоритм, определяющий множество валидных токенов). Конечно, это не полная защита, потому что пользователь может глянуть "что внутри" и понять как генерировать валидные токены. Но это же веб, о полной защите контента нет речи (в крайнем случае пользователь может вообще отскриншотить pdf и сохранить), но все же, хоть какая-нибудь защита.

Да запрет правой мышки ничего не даст.
Ну я согласен, если пользователь "ломает" ресурс по F12, то мы ничего не можем сделать. Вообще понятно, если мы отдаем файл клиенту (даже если он предназначен для pdf viewer), то этот файл тем же fiddler можно перехватить (можно же? если не fiddler, то какой-нибудь другой тулой точно можно). Так что может и нет смысла заморачиваться, завтра уточню. НО! какую-то элементарную защиту все равно можно сделать же (вот то, что я предложил).

Ну хорошо, изначально было вообще так. Сервлет вообще без параметров и без токена - просто отдает файл всем (ну, авторизованным, конечно). Т.е. просто идешь по этому сервлету и получаешь pdf файл. Единственное, чтобы узнать адрес сервлета - надо было посмотреть networking. Это нормально? Я считаю нет, поэтому добавил одноразовый токен. Ну есть же смысл в этом. Понятно, что этот токен тоже сервер выдает, и его можно так же перехватить и использовать перед тем, как pdf viewer его сожгет (поставить JS бряку во вьювере, например, чтобы застопорить pdf viewer). Но все равно уже какая-то защита. Так вот я и хочу ее сохранить, но только запросов теперь много, соответственно токенов надо много.

Это что за истина у вас такая, откуда взяли?



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

Предыстория такая: мы на все pdf документы, которые покидают систему (экспорт, скачивание файлов, отправка по email), выставляем вотермарки, на каждую страницу. Но при просмотре в pdf viewer (тот что встроен в страницу), вотермарка не выставляется. Но пользователь может легко скачать этот pdf (без вотермарки) просто перейдя по сервлету, который обслуживает этот viewer. Так вот хотелось бы ему (пользователю) побольше палок понавтывать в колеса.

Вам не лень писать чушь?

Вообще откуда вы взяли, что это "быстрый превью?" Читать учитесь, я вообще не писал ничего про "быстрый превью"

Для быстроты, только в том смысле - чтобы начать первую страницу отображать пользователю максимально быстро (а не ждать, пока весь файл загрузится "по проводам"), но в итоге это полноценный просмотр pdf. Для этого и нужна линеризация и ranged requests к серверу.

ну можете ему кошелёк отдать, своему пользователю, и массаж ещё сделать, он будет счастлив