Я хочу, чтобы мои файлы были защищены на моем веб-сервере. Доступ к этим файлам должен иметь только аутентифицированные пользователи для доступа к этим файлам. Я думал о хранении файлов в базе данных как "Long BLOB", но он поддерживает только до 2 МБ данных. Размер файла может превышать 50 МБ. есть ли другой лучший способ защитить файлы? пожалуйста, помогите мне .thanks заранее.
Не храните их в базе данных. Поместите их в свой веб-каталог и закрепите их, используя .htaccess.
Если вы хотите выполнить аутентификацию с помощью других средств, сохраните файлы в каталоге, который не доступен для веб-поиска, но доступен для чтения пользователем.
Приходят на ум несколько вариантов.
Если вы используете Apache, вы можете использовать htaccess для защиты паролем каталогов. (первая ссылка для googled: http://www.javascriptkit.com/howto/htaccess3.shtml)
или Храните файлы над веб-сервером. Создайте script в php, чтобы разрешить авторизованным пользователям доступ к ним.
Если вы хотите сделать это через FTP, и вы используете cpanel, вы можете создавать новые учетные записи ftp. проверьте yourdomain.com/cpanel, чтобы определить, установлен ли он.
Хранение файлов в БД - очень плохая практика. Очень хорошая практика хранения только информации о файле. Имя, расширение. Файлы сохраняются на сервере, например $id. $Ext. Это будет хорошая архитектура. И когда пользователь загружает файл, он берет файл с именем в БД.
Извините за мой английский.
Загружаемые файлы могут быть сохранены в htaccess protected folder/s. A script, как показано ниже, может использоваться для создания динамических ссылок для загружаемых файлов.
для ex. Безопасные ссылки для скачивания. http://codecanyon.net/item/secure-download-links/309295
Если вы решите сохранить файлы с высоким значением загружаемого содержимого непосредственно в файловой системе, лучше всего держать их за пределами веб-сети. Затем вашему приложению придется решить проблему создания URL-адресов (кодировка url при необходимости) для контента (PDF, Word Docs, Songs и т.д.).
Как правило, это может быть достигнуто с помощью запроса для извлечения пути к файлу, а затем с помощью пути к файлу для отправки контента пользователю (с помощью header() и т.д.), когда он нажимает на якорь (все это без того, чтобы пользователь не видел истинный путь на стороне сервера).
Если вы не хотите, чтобы пользовательские A пользовательские URL-адреса для загружаемого контента с высоким значением для пользователя B, ваше приложение должно каким-то образом привязать ссылки исключительно к пользователю А. Что может быть сделано? С чего начать?
Очевидно, что вы хотите, чтобы пользователь A регистрировался во время сеанса, прежде чем он или она сможет загрузить файл. Что не так очевидно, так это то, как предотвратить использование зарегистрированного пользователя B с помощью URL-адреса, отправленного пользователем A (пользователю B), чтобы загрузить A.
Использование $_SESSION для хранения зарегистрированного идентификатора пользователя (числового или строкового) и внесения этой части конечного запроса (при условии, что контент привязан к покупкам пользователя или что-то еще) предотвратит вход в систему пользователя B от загрузки вещей, которые они еще не приобрели, но вы по-прежнему будете наносить вред ресурсу для обработки пустого набора SQL для предметов, которые они не приобрели. Это звучит как хороший второй шаг.
Как насчет первого шага? Есть ли что-то, что может помешать необходимости выполнить запрос?
Хорошо, посмотрим. В HTML-форматах можно использовать маркер XSRF в скрытом поле, чтобы убедиться, что представленная форма действительно возникла с веб-сервера, который получает запрос POST/GET. Один токен используется для всей формы.
Учитывая страницу пользовательских вещей для загрузки (привязки), можно вставить один токен (тот же токен, но другой запрос на страницу) в каждый якорный атрибут href в форме параметра строки запроса и сохранения копию этого токена в $_SESSION.
Теперь, когда зарегистрированный пользователь B пытается использовать зарегистрированный пользовательский A общий URL-адрес пользователя, все происходит не так, потому что пользователь A и пользователь B имеют разные сеансы (или вообще не имеют сеанса) и, следовательно, разные токены. Другими словами, "Моя ссылка такая же, как ваша, но другая". Якоря будут привязаны к сеансу, а не только к странице, пользователю или контенту.
С помощью этой системы PHP может определить, действительно ли запрос на контент действителен, не прибегая к вовлечению базы данных (сравнивая поданный токен с тем, который находится в $_SESSION). Более того, ограничение времени может быть установлено в $_SESSION для ограничения продолжительности/срока действия действительного токена XSRF. Просто используйте функцию time() и базовую математику. Шестьдесят минут может быть идеальным временем жизни токена для якоря в этой ситуации. Повторите попытку входа пользователя, если токен для кликаемого якоря истек.
Если вы используете файлы в файловой системе и сохраняете пути в базе данных, убедитесь, что вы также выполняете следующее (как минимум).
$_SESSION, которая устраняет фиксацию сеанса.Лучший способ - сохранить ссылку на файл в базе данных. Сам файл будет сохранен в файловой системе сервера. Сложность этого заключается в том, чтобы обеспечить целостность ссылок между ссылкой на файл базы данных и существующим файлом в файловой системе сервера. Некоторые базы данных, такие как sql server 2008, имеют функцию, которая поддерживает целостность ссылок на файл для самого фактического файла.
Помимо того, что защита самого файла на сервере зависит от ОС, где разрешения могут быть настроены для конкретной папки, в которой находится файл.
Если файлы являются чисто статичными, вы можете использовать носители только для чтения или WORM для хранения файлов данных или даже запускать полный веб-сервер из "LiveCD". Это, безусловно, не подходит для всех, но для ограниченных случаев, когда целостность данных имеет первостепенное значение.