- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Как вообще реализовать приватное хранение фотографий на сервере..?
Сейчас при обращении к - атр/фотке.jpg(не существует) обрабатывает php скрипт с запросом в базу прав доступа к фотке. nginx такое вообще может закэшировать?
Вы про http://wiki.nginx.org/X-accel спрашиваете?
Вы про http://wiki.nginx.org/X-accel спрашиваете?
незнаю, нет наверное..
суть: пользователь загружает фотку на сайт, а если на сайте её хочет кому-нибудь показать, в базу пишется - пользователь id1 разрешает открыть фотку xxx.jpg пользователю id2
а когда браузер пытается открыть/загрузить эту фотку как - site.ru/atr/opt/xxx.jpg - то через mod_rewrite переменные идут в скрипт /src.php?s1=atr&s2opt&img=xxx.jpg - а он решает отдать пустую картику или настоящую фотку
---------- Добавлено 28.02.2013 в 16:17 ----------
Это всё весьма неоптимально и скорее всего некэшируемо... может можно как-то иначе?
Nginx такое может закешировать, если url получит от бакенда указание кешировать этот url. Сам url должен содержать права доступа.
То есть при формировании страницы вы определяете - показывать фотку или выдать заглушку. А nginx это послушно делает.
может закешировать, если url получит от бакенда указание кешировать этот url. Сам url должен содержать права доступа.
только что нашёл у Сысоева, и если я правильно понимаю, то это то, о чём вы говорите
location /images/ {
root /data/www;
error_page 404 = @fetch;
}
location @fetch {
internal;
proxy_pass http://backend;
proxy_store on;
proxy_store_access user:rw group:rw all:r;
proxy_temp_path /data/temp;
root /data/www;
}
но в proxy_store_access user:rw group:rw all:r; речь идёт о пользователе linux, у меня же пользователи сайта :(
---------- Добавлено 28.02.2013 в 22:32 ----------
nginx кэширует в целом url, а связать ответ апача с IP или cookies и отдавать из кэша учитывая это неполучится?
Я же вам выше написал как надо правильно делат
Andreyka, расскажите чуть подробнее. я пока не очень понял о каких правах доступа речь
Еще раз: при формировании страницы вы определяете - показывать фотку или выдать заглушку.
Делаете это в скрипте который рисует страницу. Теперь понятно?
Andreyka, ну, так оно так и было всегда.
обратился пользователь X за картинкой site/3456/9875/xxx.jpg - скрипт отдал её в соответствии с правами доступа - nginx её закэшировал, а посля уже например вы запрашиваете её же, и nginx отдаёт её вам из кэша, хотя вам её смотреть не дозволено :)
как быть?
Рекомендую такое решение
Имя каждой картинки делать в виде
1234_fjdk.jpg
1234 – номер картинки в Бд
fjdk – случайная строка для каждого файла.
Те кому можно видеть фото, получают правильную ссылку на него, а те кто не могут не получают
kruzo, приблизательно так и реализовано, но глубже..
название картинки в URL - уникально = синоним имени файла картинки в БД по которому можно вычислить права доступа. Но это всё сути не меняет
Как это всё закрутить и снизить обращения к БД и скриптам.. думал на кэше Nginx-a выехать :)