> Про свой велосипед — понимаю (хотя велосипед изобретают со времён его появления,
> и потому мы имеем современный велосипед, а не доску на колёсах,
> ну да ладно).
> Но почему с квадратными-то?Здравствуйте, Валентин!
Подгорело у меня 4 месяца назад, когда я решал задачу, по моему мнению, которая вполне распространённая и должна решаться нативно в nginx!
На самом деле уже лет 10 назад задумывался как это сделать, но не было острой нужды и до реализации не доходило.
Допустим, социальная сеть, куда пользователь заливает много картинок, которые много смотрят другие пользователи.
И к каждой картинке нужно определить кому можно смотреть - а кому нет!
Каждый пользователь заливает много фотографий и часто их смотрит и некоторые из них или личные или доступные только определённому кругу лиц, а некоторые, причём подавляющее большинство - публичные и доступны всем. Режим видимости/доступности меняется для любой фотографии или альбома.
В качестве авторизации пользователя используется сессия PHP с хранилищем в Redis.
Велосипедить со стандартной авторизацией в nginx и как-то синхронизировать её с php явно не мой вариант!
Для упрощения, приведу алгоритм, когда только владелец, когда авторизирован, должен видеть свои фотографии, а всем остальным вместо целевой картинки отдавать или картинку по умолчанию или картинку 403.
1 nginx перехватив определённый location с запросом на статический ресурс, извлекает из URI ID владельца фотографии.
2 nginx проверяет наличие и получает получает куку с сессией.
3 nginx обращается к redis чтобы провести авторизацию, проверяя есть ли в сессии такой ключ, и если есть то пользователю с каким ID он принадлежит.
4 nginx сверяет ID из URI и из сессии, и еслм иони совпадают, то статический контент отдаётся, в любом ином случае - отдаётся контент по умолчанию вместо запрашиваемого.
С 1 и 2 пунктами нативный nginx справляется, а вот с 3 и 4 по моему мнению, должен быть стандартный модуль redis, решающий эту задачу.
GPT меня сразу отправил решать задачу через OpenResty, я же до последнего не хотел его использовать и пытался решить задачу доступными и нативными модулями, на что убил 2 недели.
Существует аж 2 модуля redis
1 http_redis https://build.opensuse.org/package/show/server:http/nginx-mo...
2 redis2 https://build.opensuse.org/package/show/server:http/nginx-mo...
1-ый годится лишь для жёсткого кеширования, он ищет URI целиком и в случае успеха отдаёьт пользователю этот контент вместо целевого. И это единственное что можно с помощью него сделать.
2-ой, как оказалось, вообще не для чего не годен, так как он весь результат взаимодействия с redis тупо выплёвыут в stdout в текстовом виде, так если бы этот скопировать и вставить через консольный клиент, со всеми лишними данными, ответами, статусами.
Получит конкретный вывод, как и сохранить его в переменную нельзя!
Толку от них нет.
Я курочил njs-модуль думал что наверняка в нём, как и в lua, должен быть способ обратиться к redis, это же нативный модуль от разработчиков nginx, они наверняка должны были это реализовать, думал я до последнего!
Потом поняв как собирать lua-модуль, а для этого собрать luajit2 (форк luajit от OpenResty), да ещё и пропатчить его так, чтобы она не конфликтовал с оригинальным luajit и в системе могли существовать одновременно, и изучив lua 5.1 за 2 вечера я это сделал.
При этом в lua-модуле есть воистину Божественный lua_shared_dict https://github.com/openresty/lua-nginx-module?tab=readme-ov-...
который по функционалу напоминает redis и может кешировать ответ от redis, который будет доступен всем рабочим процессам nginx пока не истечёт срок действия или nginx не перезагрузится.
И после этого я стал считать ваш модуль njs велосипедом с квадратными колёсами, который бесполезен и вторичен по отношению к lua-модулю, который может гораздо больше, и гораздо продуманее и позволяет решать многоие типичные задачи, причём только он их позволят решать!
Вариант для распечатки
