Добрый день. Поделитесь пожалуйста идеями, как создать одноразовые ссылки для скачивания. Важное условие: невозможность узнать прямую ссылку на файл
Да. Или просто в общих чертах. Как я понимаю вариантов реализации масса. Нужно оптимальный в плане безопасности и удобства. --- Добавлено --- И еще, желательно без использования дополнительных файлов типа txt
в бд хэш заливаете , ссылку с хэшем отдаете юзеру. Он проходит по этой ссылке, site/download?hash=3453432g4343g342 скрипт сверяет на существовании такого хэша в бд и отдает файл на скачивание бд: hash name time 3453432g4343g342 || /download/revwvsvre/1.lol || время существовании этой ссылки (UNIX time)
перед тем как отдавать файл, скрипт чистит просрочку --- Добавлено --- всмысле? ты просто заполняешь бд как в примере
Например, отдал я ссылку с хешем юзеру 1, в этот момент юзер 2 тоже запросил файл и скачивает его раньше юзера 1. В этот момент я чищу токен. Получается, что у юзер 1 будет не актуальный хеш.
Юзера от юзера тоже же надо отличать, поэтому, мне кажется, отдельная таблица, где ID-юзера, хэш, и идентификатор, скачал или не скачал. Можно подумать о времени жизни хэша, например, в куках. Ну а есть ли смысл чистить таблицу? если она будет отдельная, места много не займет(несколько Кбайт), периодически ее можно чистить (DROP-ать), во время профилактических работ.
Тогда каким образом юзер 1 сможет вновь получить ссылку? --- Добавлено --- Согласен, есть зарегистрированный и незареганый
не обязательно регистрироваться, зашел на сайт, получил куку, (а дальше с ним че хотите то и делайте с этим пользователем), получил ссылку - в куке хэш, еще раз ссылку получил в куке хеш перезаписался
я предлагал как-то создавать линку на файл, чтобы файл отдавался вебсервером минуя пхп но идею я не тестировал.
Предлагаю после первого же скачивания удалить ссылку на хеш в бд, тогда файл будет не доступен второй раз по этой же ссылке. Если он по какой то причине не скачал выдаёте ему такую же одноразвую ссылку через тех поддержку. А ссылку нужно конфигурировать именно так чтобы подбором она никогда не подобралась, а это не так сложно. --- Добавлено --- А ещё лучше запаролить ссылку и отдать лог и пас на почту пользователю, ну и всё , скачать может тот у кого есть пароль. Вот вам и безопасность. --- Добавлено --- Пароль уникален, для каждой созданной ссылки.
@askanim это слишком круто, ориентируясь на первый пост --- Добавлено --- так ссылка как бы тоже уникальна. если ее передать другому юзеру, это аналог тому что ты скажешь пароль для доступа
значит пароль + после того как зашёл скачал, удалилась ссылка. --- Добавлено --- работы от силы на три часа. Создать таблицу, для хранения данных о ссылках на файл, т. есть уник Id + хеш + имя файла которое будем качать, зашли значит по ссылку чекнули в бд этот хеш ага есть отдали файл, файл отдался ссылка удалилась (то бишь удалили строчку с бд, или пометили как уже отдавшуюся раздачу, и её больше не отдаём, а значит в логике уже изменения, добавляем поле в таблице какое нибудь аля check и взводим его в boolen по умолчанию храним в false, скачали поставили true, то бишь изначально чекаем ссылку и попутно проверяем false или true если false отдаём и в конце ставим true, А ещё фише дабы не засерать дб , удаляем строку из бд, а если надо хранить инфу о скачиваниях создаём некую дублёжную таблицу log_check, и скачаные строки ложим туда тогда алгоритм тоже слегка другой). Компренде. А то и на час работы
лишний блэкджек, одноразовая ссылка на мыло юзеру пришла и все, успел заюзать ? молодец.. скачал.. удалилась ссыль. Не успел по таймауту? пухом земля --- Добавлено --- зачем? если нужно вывести инфо про использованные ссылки, достаточно выбрать с условием "использованный презерватив"
Подкину идею: саму уникальную сгорающую ссылку можно нигде не хранить. Ссылка может содержать в своём теле всю необходимую информацию, так зачем в какой-то базе её хранить? Можем смело генерировать такие ссылки "на лету" и не бояться накопить стопицот миллионов. Например поля из ссылки: - id ресурса - крайняя дата использования и опционально - id пользователя, которому дали право все эти переменные подписываем секретным ключем, например с помощью HMAC чтобы можно было проверить достоверность. Подпись также помещаем в ссылку. http://example.com/file?id=12345&until=20180308&crc=g69fe0ddcb7a Получили запрос на ресурс, выделили значимые поля, проверили подпись, проверили дату (и опционально пользователя). Eсли всё хорошо — отдаём ресурс. А нет, так лови гранату статус 403. Не очень хорошая идея делать буквально "одноразовые ссылки для скачивания". Закачка может обломаться по какой-то причине, особенно если файл большой. Надо чтобы авторизованный на скачивание пользователь мог повторить попытку в пределах какого-то времени. Одноразовые ссылки применяются для другого: для ссылок, которые авторизуют пользователя на какое-то действие в обход аутентификации. Например вы можете получить на почту ссылку на смену пароля. Такая ссылка не должна работать при повторном заходе.