会话/身份验证如何与nginx / NHPM / PHP-FPM一起使用？

Question

So, I'm looking at architecting an application using nginx with the nginx-http-push-module and PHP-FPM, and after lots of fun configuring, I got it working to the point of handling PHP pages as it should.

What I don't get, though, is how sessions are supposed to work - all of the examples I've seen for nginx+NHPM run through the publisher-subscriber system, but it's never clear what should happen if the subscriber channel is going to be, effectively, unique to a subscriber. Think of a chat system with a public channel and a private channel for each user, for example.

Now, in a conventional PHP setup, you'd be passing the cookies to PHP, looking up the session from there, and handling the rest of the page based on whether the user was authenticated or not, but with PHP-FPM and long-polling, it doesn't seem like it should work like that.

I can understand if the request is a non authenticated user, you just dump them with an error message and terminate the long-poll from the client knowing that it's not valid, but with a valid request, you almost need to poll from the client, authenticate in PHP, then disconnect but leaving the request open - and I'm not sure how that part works.

Can anyone explain how it should be achieved, ideally with an example if possible? Please note I'm not looking for HTTP Basic authentication here, I need the authentication to be looked up against a separate data storage which is in MongoDB.

Answer 1

Disclaimer: I can't clearly understand your 4. paragraph.

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

A possible solution follows, I'll be trying this out in the next days.

nginx configuration:

• push_subscriber_concurrency first: 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:

1. Client sends credentials via old-fashioned requests
2. Server authenticates, and generates a token (channel id). Creates the channel and responds with the token.
3. Client tries to open long-poll to the given channel.
   • If it fails (possibly because the channel was hijacked), it tells the server that channel so-and-so is invalid. Mind that we use old-fashioned requests here, so you can use any auth method. Server deletes the channel. Back to step two.
   • If the connection is successful (you probably won't know this, only that it hasn't failed), the channel can be considered authenticated.

Note that if your application should be accessible from multiple pages in the same browser with the same login, then you'll need to prepare for multiple channels per user.