Предотвращение прямого доступа к изображениям с использованием URL-адреса браузера

У меня есть папка с именем – Images . Эта папка содержит фотографии профиля пользователя. Прямо сейчас пользователь может видеть его изображение, просто копируя URL-адрес изображения в свой браузер в любое время. Таким образом, он также может видеть фотографии других пользователей. Я хочу достичь – пользователь должен иметь возможность видеть свой профиль pic только через страницу PHP на моем веб-сайте. Если пользователь напрямую помещает URL-адрес изображения, он не должен отображаться.

Я пытался добиться этого, используя .htaccess. Это то, что у меня есть в файле .htaccess:

RewriteEngine On RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://(www\.)?mysite.com/ RewriteRule \.(gif|jpg)$ http://www.mysite.com/errorpost.jpg [R,L] 

Я новичок в .htaccess. Если есть способ достичь этого, пожалуйста, помогите.

Заранее спасибо.

    У меня такая же проблема. В настоящее время я нашел 2 способа:

    1) base64_encode () + ajax + js / jquery

    • Храните каждое изображение, закодированное base64_encode () в двоичном файле или базе данных OUTSIDE www.
    • Используйте ajax для получения этих данных. он должен возвращать «данные: image / jpeg; base64, $ enc_imgbinary»
    • Замените атрибут 'src' из 'img' с возвращенным результатом с помощью js / jquery

    профи

    • невозможно получить доступ к изображению с прямой ссылкой

    минусы

    • Я не нашел подобного решения для видео.
    • изображения должны быть закодированы заранее (или первое использование), чтобы минимизировать использование ЦП сервера.
    • закодированные изображения занимают около 30% пространства на диске => 1.3x дисковое пространство
    • если вы хотите сохранить исходные изображения на сервере => 2.3x дисковое пространство.
    • ~ 30% больше данных будет отправлено по сети

    2) длинные случайные имена (+ символические ссылки)

    A) Сохранение изображений в папке www с использованием длиннослучайных имен
    B) Храните изображения вне www-папки с символическими ссылками на www-папку. (изображения вне www также могут работать как резервная копия на рабочем столе)

    заметки:

    • папки должны также содержать случайные символы
    • использовать '.' перед любой папкой или именем файла => на всякий случай, чтобы предотвратить отображение содержимого папки на unconfigured apache
    • настроить apache для обозначения символических ссылок в случае B) (добавить FlowSymlinks в httpd.conf)
    • настроить apache для запрета содержимого содержимого папки (удалить индексы из httpd.conf)
    • пример иерархии изображений:

      • WWW
        • .media_jmdue7jed
          • .user1_hash_! sdfsewewfsdfsds
            • .album1_name_! jfie8e7y77667fef
              • .photo1_name_! kjio9i890v8fsd978fyreshf
              • .photo2_name_! 09098dfuujdsif87s7ysdffd
            • .album2_name_! ghhyuflp! huidfjh
              • .photo1_name_! feojihudhufuuhfrufhi8484
              • .photo2_name_! 2344gfdgfdgdfefedw232sdg
          • .user1_hash_! j333re89dsfdsf

    плюсы:

    • Может использоваться и для видео
    • Вы все равно можете сохранять оригинальные изображения с оригинальными именами вне www-папки, создавая символические ссылки на www-папку с использованием длинно-случайных имен. Даже для каждого пользователя.
    • Изображение можно использовать за пределами вашего сервера (в форумах, быстро отправить прямую ссылку вашему другу или тому подобное)

    минусы

    • символические ссылки должны быть созданы заранее (или на лету)
    • Доступ к изображению можно получить по прямой ссылке
      • однако его почти невозможно догадаться
      • также вы можете изменить периодическое периодическое имя символьной ссылки или изменение прав на изображение (я хочу, чтобы google + сделал это)
    • map original-name → long-random-name должно храниться в db (или sidecard / meta file)
      • (можно обойти, если вы сохраняете имя оригинала внутри длинного случайного имени путем кодирования / декодирования или путем объединения имени оригинала + длинного случайного имени)

    =====================================

    Я реализовал случай 1), и это сработало для меня хорошо, однако я не нашел подобного решения для видео HTML5.

    Случай 2) представляется более гибким. Однако я все еще не уверен в безопасности. Если кто-нибудь увидит дыры в безопасности, пожалуйста, дайте мне знать.