Как работает сеанс/аутентификация с nginx/NHPM/PHP-FPM?

Question

Итак, я смотрю на архитектуру приложения с использованием nginx с модулем nginx-http-push-module и PHP-FPM, и после много забавного конфигурирования я получил его, работая с точки зрения обработки страниц PHP так, как должен.

Однако, я не понимаю, как работают сессии - все примеры, которые я видел для nginx + NHPM, запускаются через систему подписчиков издателей, но никогда не ясно, что должно произойти, если абонентский канал будет, по сути, уникальным для абонента. Например, подумайте о системе чата с общедоступным каналом и частным каналом для каждого пользователя.

Теперь, в обычной установке PHP, вы передаете файлы cookie на PHP, просматривая сеанс оттуда и обрабатывая остальную страницу на основе того, был ли пользователь аутентифицирован или нет, но с PHP- FPM и длительный опрос, похоже, что он не должен работать так.

Я могу понять, если запрос является не прошедшим проверку подлинности пользователем, вы просто сбрасываете их с сообщением об ошибке и завершаете длинный опрос от клиента, зная, что он недействителен, но с действительным запросом вам почти необходимо опросить от клиента, аутентифицироваться на PHP, а затем отключить, но оставить запрос открытым - и я не уверен, как эта часть работает.

Может ли кто-нибудь объяснить, как это должно быть достигнуто, в идеале с примером, если это возможно? Обратите внимание, что я не ищет HTTP-аутентификацию здесь, мне нужна проверка подлинности, которую нужно искать против отдельного хранилища данных, находящегося в MongoDB.

Answer 1

Отказ от ответственности: Я не могу четко понять ваш 4. пункт.

Насколько я могу судить, основной проблемой при аутентификации в NHPM является то, что приложение PHP получает абсолютно нулевое уведомление о входящих соединениях. Кометная часть вашей установки предназначена для записи только для PHP.

Возможное решение следует, я попробую это в ближайшие дни.

конфигурации Nginx:

• push_subscriber_concurrency первый: так что канал может быть использован только намеченным пользователем
• push_authorized_channels_only на: не является строго необходимым, но хорошо иметь по-моему

Рабочий процесс авторизации:

1. Клиент отправляет учетные данные через старомодные запросы
2. Сервер аутентифицирует и генерирует токен (идентификатор канала). Создает канал и отвечает токеном.
3. Клиент пытается открыть длинный опрос по данному каналу.
   • Если это не удается (возможно, потому, что канал был захвачен), он сообщает серверу, что канал так и недействителен. Имейте в виду, что здесь мы используем старомодные запросы, поэтому вы можете использовать любой метод auth. Сервер удаляет канал. Вернемся к шагу 2.
   • Если соединение успешное (вы, вероятно, не знаете этого, только то, что оно не сработало), канал можно считать аутентифицированным.

Обратите внимание, что если ваше приложение должно быть доступно из нескольких страниц в одном браузере с тем же логином, то вам необходимо подготовить для нескольких каналов для каждого пользователя.