¿Cómo funciona la sesión/autenticación con nginx/NHPM/PHP-FPM?

Question

Por lo tanto, estoy buscando diseñar una aplicación usando nginx con el nginx-http-push-module y PHP-FPM, y después de mucha configuración divertida, lo hice funcionar al punto de manejar las páginas PHP como debería.

Lo que no entiendo, sin embargo, es cómo se supone que funcionan las sesiones: todos los ejemplos que he visto para nginx + NHPM se ejecutan a través del sistema editor-suscriptor, pero nunca está claro qué sucedería si el canal del suscriptor va a ser, efectivamente, exclusivo de un suscriptor. Piense en un sistema de chat con un canal público y un canal privado para cada usuario, por ejemplo.

Ahora, en una configuración convencional de PHP, estaría pasando las cookies a PHP, buscando la sesión desde allí, y manejando el resto de la página según si el usuario fue autenticado o no, pero con PHP- FPM y larga encuesta, no parece que debería funcionar así.

Entiendo que si la solicitud es un usuario no autenticado, simplemente envíe un mensaje de error y termine la encuesta larga del cliente sabiendo que no es válida, pero con una solicitud válida, casi necesita sondear del cliente, autentíquese en PHP, luego desconéctese pero deje abierta la solicitud, y no estoy seguro de cómo funciona esa parte.

¿Alguien puede explicar cómo se debe lograr, idealmente con un ejemplo si es posible? Tenga en cuenta que estoy no buscando la autenticación HTTP básica aquí, necesito que la autenticación se compare con un almacenamiento de datos separado que se encuentra en MongoDB.

Answer 1

Descargo de responsabilidad: No puedo entender claramente su 4. párrafo.

Por lo que puedo decir, el principal problema con la autenticación en NHPM es que la aplicación PHP recibe absolutamente ninguna notificación de las conexiones entrantes. La parte de Comet de su configuración es solo de escritura para PHP.

Una posible solución a continuación, voy a probar esto en los próximos días.

configuración de nginx:

• push_subscriber_concurrency primero: para que el canal sólo puede ser utilizado por el usuario previsto
• push_authorized_channels_only en: no es estrictamente necesario, pero es bueno tener en mi opinión

Flujo de trabajo de autorización:

1. El cliente envía las credenciales a través de solicitudes anticuadas
2. El servidor se autentica y genera un token (identificador de canal). Crea el canal y responde con el token.
3. El cliente intenta abrir el sondeo largo al canal determinado.
   • Si falla (posiblemente porque el canal fue secuestrado), le dice al servidor que ese canal no es válido. Tenga en cuenta que usamos solicitudes pasadas de moda aquí, para que pueda usar cualquier método de autenticación. El servidor borra el canal. Volver al paso dos.
   • Si la conexión es exitosa (probablemente no lo sepa, solo que no ha fallado), el canal puede considerarse autenticado.

Tenga en cuenta que si su aplicación debe ser accesible desde varias páginas en el mismo navegador con el mismo nombre de usuario, entonces usted necesita para preparar para múltiples canales por usuario.