How does session / authentication work with nginx / NHPM / PHP-FPM?

Question

So, I look at the architecture of an application using nginx with the nginx-http-push-module and PHP-FPM module, and after a lot of fun configuration I got it while working on how to process PHP pages as it should be.

However, I don’t understand how the sessions should work - all the examples that I saw for nginx + NHPM are run through the publisher’s subscriber system, but they never figure out what happens if the subscriber’s channel is essentially unique to the subscriber. For example, think of a chat system with a public channel and a private channel for each user.

Now, in a typical PHP installation, you transfer cookies to PHP, viewing the session from there and processing the rest of the page based on whether the user has been authenticated or not, but with PHP-FPM and a lengthy survey, it seems that it should not work like that.

I can understand if the request is an unauthenticated user, you simply discard them with an error message and complete a long poll from the client, knowing that it is invalid, but with a valid request you almost need to poll the client, authenticate to PHP, and then disconnect, but leave the request open - and I'm not sure how this part works.

Can someone explain how this should be achieved, ideally with an example, if possible? Please note: I am not looking for HTTP authentication here, I need authentication that I need to look for against a separate data store located in MongoDB.

Answer 1

Disclaimer: I cannot clearly understand your 4. clause.

As far as I can tell, the main problem with authentication in NHPM is that the PHP application receives absolutely zero notification of incoming connections. The comet part of your setup is written for PHP only.

The next possible solution, I will try this in the coming days.

Nginx configuration:

• push_subscriber_concurrency: so that the channel can only be used by the intended user.
• push_authorized_channels_only on: not strictly necessary, but good to have in my opinion

Authorization Workflow:

• Client sends credentials through old-fashioned requests
• The server authenticates and generates a token (channel identifier). Creates a channel and responds with a token.
• The client is trying to open a long poll on this channel.
  • If this fails (possibly because the channel was captured), it tells the server that the channel is still invalid. Keep in mind that we use old-fashioned queries here, so you can use any auth method. The server removes the channel. Back to step 2.
  • If the connection is successful (you probably do not know this, only that it did not work), the channel can be considered authenticated.

Please note that if your application should be accessible from several pages in one browser with the same name, you need to prepare several channels for each user.