I have multiple internal servers calling the API gateway and I need to know which internal server is making the API call. I have the IP address of the original forwarded service (via proxy.client.ip and an XFF header) but I actually need the hostname for various reasons. It would be ideal to look up the hostname via reverse DNS, but there doesn't seem to be a way to do that without creating some other service to do the reverse DNS for me. External reverse DNS services wont work since it's an internal hostname.
My question is, what's the best way of getting the hostname of the original API caller?
Solved! Go to Solution.
If you're doing this in a controlled, API Centric environment, then... you won't be concerned with the hostname of the caller.
Just issue multiple different credentials to the different caller apps, and then with VerifyApiKey or VerifyAccessToken you will be able to identify the client, irrespective of the hostname.
But maybe you need the hostname anyway. (I can't imagine why, but I guess it's possible)
There is no magic to discovering the hostname of the caller without doing a reverse DNS lookup. It is possible for you to design the API interface to require the client to pass a hostname, for example in an X-client-hostname header. But, this will be a "voluntary compliance" thing and a client could pass anything it likes. If you control the clients, then it's just a matter of making sure the client apps do the right thing.
If you don't control the clients, then ... you have to persuade the developers of those outside clients to pass something valid.
One way you might "enforce" a valid hostname is to, again, rely on Apigee app credentials. Require client devs to register a list of max 3 hostnames that might be used for their client systems, and store that as a custom attribute on the credential. And then at runtime,
What do you need the hostname for anyway?
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |