Block until NAME::lookup returns?

Well, there are ways to implement a wait loop, but don't -- it will lock up the thread and cause a watchdog reboot and failover if the name lookup takes too long.

 

 

Instead, I'd use "TCP::notify request" command to trigger the USER_REQUEST event and carry on there. You'd need to save off to local vars all the info required for auth, then collect & call NAME::lookup in HTTP_REQUEST, call TCP::notify from NAME_RESOLVED, and continue in USER_RESPONSE event with the auth commands using the vars saved earlier. (I see you are already setting a "mustauth" flag", so where you are evaluating that flag might be the place to use TCP::notify.)

 

 

I mentioned local variables specifically because I noticed you are using a global variable for the client IP ($::clientIP). Connection-specific data should NOT be saved in global variables, or you are sharing data across connections, in this case you could be looking up the wrong client IP if another connection has populated that variable since this connection first did. If, for example, your mustauth flag were set as a global, the flag value could change several times during the current connection as other connections are processed in parallel, and again, you might be acting on the wrong data to make your auth decision.

 

 

It's also worth pointing out how easy it is to spoof the name for a reverse resolution, and since the intent here is to bypass auth based on such a perilous assumption as the accuracy of a PTR record, you might want to consider re-evaluating this approach security-wise.

 

 

HTH

 

/deb