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

Question

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

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

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

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

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

Answer 1

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

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

Ниже приведено возможное решение, я опробую его в ближайшие дни.

Конфигурация nginx:

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

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

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

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