Задать вопрос

Вячеслав

Лайки

  • Доступ к изображению только для конкретных сайтов (белый список)

    nowm
    @nowm
    Если у вас Apache в качестве веб-сервера, можно не нагружать PHP выяснением того, кто откуда пытается загрузить картинку. Ведь в случае PHP вам все-все картинки придётся отдавать PHP-скриптом — это какая-то лишняя нагрузка.

    С помощью .htaccess можно сделать примерно такой вариант (файл .htaccess в корне сайта files.domain.com):

    RewriteEngine On
RewriteBase /

RewriteCond %{HTTP_REFERER} !domain\.com$ [NC]
RewriteRule .* - [R=404,L]


    Я могу ошибаться немного в регулярных выражениях, но суть, я думаю, понятна: проверяем, чтобы строка %{HTTP_REFERER} заканчивалась на «domain.com» (сюда попадут и «domain.com» и «www.domain.com» и «image.domain.com» и «любойподдомен.domain.com»). Если реферер не подходит под это определение, редиректим на страницу 404.

    %{HTTP_REFERER} — это содержимое HTTP-заголовка Referer.

    С другой стороны, Referer можно легко подделывать с помощью PHP, и злоумышленник может написать на PHP простой прокси, который будет по своим адресам отдавать ваши картинки, отправляя вам легитимное значение поля Referer.
    Ответ написан
    1 комментарий
    1 комментарий

  • Сколько осталось жить php?

    begemot_sun
    @begemot_sun
    Программист в душе.
    Потом будет пенсия. Если Вы 6 лет работали с PHP и больше ничего не трогали, не знаете, не развивались - то я вам могу только посочувствовать.

    Важен не сам по себе язык. Язык - это инструмент которым вы решаете текущие задачи. Что касается, PHP или чего-то другого -- безусловно гарантировать актуальность данной технологии через 20 лет никто не будет. Но думаю в ближайшие 5-8 лет PHP останется там где он есть - в вебе. Ему в конкуренты придут новые языки, и потеснят его. Соответственно спрос будет только падать.
    Ответ написан
    3 комментария
    3 комментария

  • Сайт, способный выдержать высокую нагрузку (?)

    @zuborg
    Хочу сразу все сделать правильно
    Все хотят, да вот ни у кого не получается ;)

    стоит ли тогда заморачиваться с выбором базы данных?
    Разумеется, хранить надо в отдельной базе данных, можно и файловой. А то когда захочется шаблон html-ки поменять, будет не смешно.

    Казалось бы, что может быть проще и легковеснее, чем отдавать статичные .html файлы
    Собственно, ничего, поэтому для незалогиненых пользователей, которые генерируют 90% трафика, стоит использовать именно статичные .html файлы. Запросы пользователей, которым надо генерить индивидуальные странички, надо направлять на движок в обход кеша (например, по факту наличия соотв сесионной куки).

    Где лучше хранить кэш с .html документами?
    в соотв. documentroot, чтобы nginx мог их легко найти и отдать, прямо по запрашиваемому урлу. Крайне желательно поддерживать некоторую вложенность папок, чтобы в каждой папке было максимум несколько тысяч файлов или других папок.

    Или может все хранить в тех же файлах?
    Все нельзя. Только то что редко обновляется и долго остается валидным. Для короткоживущих данных лучше использовать все-таки memcached, во избежание лишней нагрузки на диск. Либо FS в памяти, если уж хочется работы с файлами. Для короткоживущих данных в php есть замечательное средство кеширования — pecl модуль APC (основное его предназначение opcode cacher, но данные он тоже может кешировать)

    У работы с файловым кешем свои тонкости. Например, данные в нем менять надо атомарно, т.е. через временный файл и последующий rename(). Также желательно использовать блокировки чтобы избежать ситуации, когда несколько запросов паралельно начинают генерировать один и тот же элемент кеша. Часто нет необходимости немедленно перегенерировать элемент кеша при обновлении данных, достаточно его удалить, а генерация произойдет при запросе.
    Ответ написан
    Комментировать
    Комментировать