I’m playing with HTTP authentication and trying to implement a multi-step handshake using the .z.achandler. The more detailed definition is that I’m writing a Kerberos/SPNEGO authenticator that can require several messages back-and-forth before the q server can bless the connection and return (1;”username”).
Typically when returning a 401 response with the WWW-Authenticate: Negotiate header, it’s a one-shot thing and the Linux GSSAPI library does not want to send data back to the browser. However, I want to get that covered, and so want to be able to register the file-descriptor against a “context handle” so that when I get the reply I can carry on where I left off.
Now, the nub of the problem is that I can’t seem to get the socket-close event via .z.pc (and also not via .z.wc). This means in turn that I can’t delete the context-handle I’ve got lying around and the next HTTP request reuses the same FD, leading to misery and corruption.
Am I being really dense and missing something obvious?
.z.ac can be thought of as protection for the get/post/etc (.z.ph/.z.pm/.z.pp). Depending on whats returned from it to say ok or not, the corresponding callback is called.
HTTP is generally stateless (unless a developer applies logic to add/track state). So a disconnection doesnt normally indicate the client is gone, as multiple requests can end up as multiple short term connections. Hence the lack of disconnection callbacks as they would be called extremely often for this.
By adding state, you can do this such as a dict/table to track a users state. This might contain things like their state in the login process, last interaction time, failed login, etc. The file descriptor/handle is typically not a good thing to track with (as the same client can use multiple/different or a different client could end up using the same fd). Theres concepts like tokens/cookies/etc … if they aren’t passed from client they are treated as not logged in, when they login they are given to client & client must use them on subsequent sends (which are then validated). When they are sent, they are used as a lookup to the user table to update/check state.
A general time (.z.ts) could be running, and inspect the table to clear down and invalidate anything thats x minutes old based on their last interaction time (clearing up memory & forcing users to auth again if they reappear).
authentication/autorization/etc is a fairly big topic but hopefully this gives some ideas of avenues to look at or consider.
Yes, agreed. In particular, that HTTP is (meant to be) stateless. However, sequenced message-exchange specified in RFC 4559 becomes hard to implement in the absence of close-events, especially if a browser uses multiple concurrent connections.
Without close-events, you’ve got a couple of choices, I guess: store state in cookies (and hope that concurrent connections don’t foul things up), or send a redirect with a URL parameter to identify a message chain. Having coded-up the cookie-approach I’ll see how the redirect works out.
If you did have close-events you could reason about whether the browser is replying to your challenge. Of course, were it completely obtuse, it could interleave a completely different request on the same TCP connection. It feels a lot harder than it should be.