Как в Nginx реализовать проверку auth_request самим nginx без скриптов?

Question

[Boris Köln]

Есть высоконагруженный сайт.
1. Есть одна страница аутентификации /login, которая обрабатывается PHP, проверяет логин/пароль (он приходит из обычной html-формы), записывает данные в сессию и куку. Обращений очень мало.
2. Есть одна страница авторизации /auth, которая обрабатывается PHP, проверяет, есть ли у аутентифицированного юзера права доступа к определенной странице. Возвращает код 200 или 403.
3. Весь остальной контент - в виде заранее сгенерированных html-страниц, которые отдаются nginx без PHP. Некоторые страницы общедоступны, некоторые доступны только залогиненным, некоторые только юзерам с определенными правами. Проверка прав доступа осуществляется с помощью nginx модуля auth_request, то есть на каждое обращение к html-странице делается подзапрос к /auth (см. п. 2) с передачей $request_uri, что создает лишнюю нагрузку.

Для оптимизации планирую избавиться от использования PHP в п. 2. Как эту же проверку можно реализовать на самом nginx, то есть как по id юзера ($http_cookie) и запрошенному URI ($request_uri) проверить права с помощью nginx?
Допустим, заранее могу генерировать некоторые файлы с перечнем прав всех юзеров. В каком формате лучше? В голову приходит только структура auth/user/$iserId/$request_uri , то есть проверять наличие файла. Если есть - 200, иначе 403. Но юзеров может быть очень много. Можно всех юзеров записать построчно в файл на каждый URI, но как тогда парсить этот файл из nginx?
Можно эти данные записывать в memcache, но он не гарантирует надежного хранения данных.
Может, в какую-нибудь быструю БД, доступ в которую Nginx может сделать сам?
Или написать демона на java или node.js? Но это потенциально лишняя точка отказа.

Comments

[Lynn «Кофеман»]

Если у вас простая проверка пользователя создаёт значительную лишнюю нагрузку, то вы что-то не так делаете

[Boris Köln]

Проверка - RBAC на основе PHP-массива без БД.
Создает нагрузку не сама проверка, а лишний http-подзапрос к ней на каждую страницу даже при использовании Nginx и PHP-fpm. При высокой нагрузке это приходится учитывать.

Answer 1

[egor_nullptr]

Можно сгенерировать конфиг для nginx с использованием map

#auth.conf
map $user_id:$request_uri $allow {
    default 0;
    1234:/path/page1.html 1;
    1234:/path/page2.html 1;
    5678:/path/page1.html 1;
    ...
}

И подключать в конфиге хоста

#host.conf
include "auth.conf";
server {
    listen 80;
    server_name host.org;

    root /path/to/static/pages;

    location / {
        auth_request /_auth;
    }

    location = /_auth {
        if ($allow) {
            return 200;
        }
        return 403;
    }
}

Comments

[Boris Köln]

Хороший быстрый вариант.
Но есть и минус: при регистрации нового юзера придется из PHP как-то под рутом перегружать Nginx, чтобы подключить новый конфиг.

[egor_nullptr]

Можно использовать sudo с разрешением пользователю php только одной конкретной команды
exec("sudo service nginx reload");

[Boris Köln]

Только не это!
Лучше уж флажок (например, файл) и башем по крону под рутом проверку наличия файла, перезагрузку и удаление файла.

Answer 2

[Александр N++]

можно через

session_log_module
mysql_module

смотрим location /auth {
через session модуль получаем ид сессии
смотрим через mysql модуль таблицу сессий
смотрим авторизован или нет.
если нет то на страницу такую...
}

стоит также добавить что в php придется переопределить механизм хранения сессий на БД
через session_set_save_handler
на странице авторизации устанавливаем после авторизации сессию через обычный пых.

это все в теории.
сам модуль mysql под ngnix использовал, впечатления только положительные
еще рекомендую обновить php7+ он быстрей на 50% чем прошлая версия, особенно это чувствуется на работе с массивами.

Comments

[Boris Köln]

php -v

PHP 7.1.4 (cli) (built: Apr 15 2017 08:26:32) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.1.4, Copyright (c) 1999-2017, by Zend Technologies

Создает нагрузку не сама проверка, а лишний http-подзапрос к ней на каждую страницу даже при использовании Nginx и PHP-fpm. При высокой нагрузке это приходится учитывать.

[Boris Köln]

Сейчас использую проверку RBAC на основе PHP-массива без БД.
Что-то мне подсказывает, что обращение к MySQL будет не лучше обращения к PHP.