Come funziona la sessione/autenticazione con nginx/NHPM/PHP-FPM?

Question

Quindi, sto studiando un'applicazione che utilizza nginx con nginx-http-push-module e PHP-FPM e, dopo molte divertenti configurazioni, ho lavorato sul punto di gestire le pagine PHP come dovrebbe.

Quello che non capisco, però, è come dovrebbero funzionare le sessioni: tutti gli esempi che ho visto per nginx + NHPM funzionano attraverso il sistema di sottoscrizione dell'editore, ma non è mai chiaro cosa dovrebbe accadere se il il canale dell'abbonato sarà, in effetti, unico per un abbonato. Pensa a un sistema di chat con un canale pubblico e un canale privato per ciascun utente, ad esempio.

Ora, in una configurazione PHP convenzionale, passeresti i cookie in PHP, cercando la sessione da lì e gestendo il resto della pagina in base al fatto che l'utente fosse autenticato o no, ma con PHP- FPM e polling lungo, non sembra che dovrebbe funzionare in questo modo.

Posso capire se la richiesta è un utente non autenticato, è sufficiente scaricarli con un messaggio di errore e terminare il polling lungo dal client sapendo che non è valido, ma con una richiesta valida, è quasi necessario effettuare il polling dal client, autenticarsi in PHP, quindi disconnettersi lasciando aperta la richiesta - e non sono sicuro di come funzioni quella parte.

Qualcuno può spiegare come dovrebbe essere realizzato, idealmente con un esempio se possibile? Si prega di notare che io sono non cercando l'autenticazione di base HTTP qui, ho bisogno dell'autenticazione per essere guardato contro una memoria separata di dati che è in MongoDB.

Answer 1

Disclaimer: Non riesco a capire chiaramente il tuo 4. paragrafo.

Per quanto ne so, il problema principale con l'autenticazione in NHPM è che l'applicazione PHP ottiene una notifica assolutamente nulla delle connessioni in entrata. La parte Comet del tuo setup è di sola scrittura per PHP.

Una possibile soluzione segue, ci proverò nei prossimi giorni.

configurazione nginx:

• push_subscriber_concurrency prima: in modo che il canale può essere utilizzato solo dall'utente destinato
• push_authorized_channels_only on: non è strettamente necessario, ma buona per avere, a mio parere

Flusso di autorizzazione:

1. Il client invia le credenziali tramite richieste obsolete
2. Il server esegue l'autenticazione e genera un token (id canale). Crea il canale e risponde con il token.
3. Il client tenta di aprire il polling lungo al canale specificato.
   • Se non riesce (probabilmente perché il canale è stato dirottato), comunica al server che il canale così e così non è valido. Ricorda che qui utilizziamo richieste obsolete, quindi puoi utilizzare qualsiasi metodo di autenticazione. Il server elimina il canale. Torna al passaggio due.
   • Se la connessione ha esito positivo (probabilmente non lo saprai, solo che non ha avuto esito negativo), il canale può essere considerato autenticato.

Si noti che se l'applicazione deve essere accessibile da più pagine nella stessa browser con lo stesso login, allora avrete bisogno di prepararsi per canali multipli per utente.