Gotcha #3: Client Details
Some applications require information about the client (browser) including its IP address. While most information about a client such as browser, plug-ins, content accepted, etc is carried along in the HTTP headers of a web application, the IP address is not. When a web or application server queries for the client IP address the data is pulled from the network protocol information, not HTTP.
When a proxy service is inserted into the middle of client-server communication it can, and often does, change the network information. This is often necessary in order to facilitate load balancing, transformation, and security functions on the proxy. In many cases, this means that the IP address returned from a query on the web or application server is actually the IP address of the proxy service, not the client. In other cases query returns the expected result: the client's IP address. This is because the proxy service is sitting between a public network (the Internet) and a private network (the cloud data center). When it receives a request it has to translate between the two, and in many network architectures this means it must change the network information so it can communicate with the private network, and then change it back after receiving the response to communicate with the public network. Even though your application is assigned a public IP address, that is usually the IP address of the application delivery or load balancing service, not the actual application, and therefore a translation must occur in order for communication to appear seamless.
If the cloud computing or load balanced environment is not preserving the client IP address and your application or corporate policies require tracking client IP addresses every client will appear to be the same: it will have the IP address of the proxy.
As this has long been an issue in load balanced environments, a solution exists that solves the problem by having the proxy service insert the actual client IP address into a custom HTTP header called X-Forwarded-For. When the proxy service receives a request from the client it extracts the client's IP address and inserts it into the X-Forwarded-For HTTP header before sending the request on to the appropriate application instance. Most hardware and software application delivery solutions are capable of inserting this custom HTTP header. If the cloud computing provider has built their own solution, it may not be available or they may have used a different customer header.
The possibility that the client IP address is not the "real" client IP address can be problematic even if you don't need the address for your application as it also ends up in logs incorrectly, posing a problem for applications requiring a more accurate transactional log.
- Inquire of the cloud computing provider whether the client IP address is preserved or inserted in the X-Forwarded-For HTTP header before you deploy your application. If it is preserved, you won't need to change a thing. If it isn't and the provider has implemented the use of X-Forwarded-For, skip to solution #2.
- By default, query for client IP addresses by examining the value of the HTTP header X-Forwarded-For first, and if it is empty continue on to query the web or application server for the client IP address. Doing so will insure that when the application is inserted into a load balanced environment that it is ready to deal with the change in location and no modification will be necessary.
- If it is imperative that you be able to obtain the correct client IP address for auditing or for your application to work properly be sure to inquire about the cloud computing provider's handling of client IP addresses before you sign up. If they cannot provide an accurate IP address you will likely want to look elsewhere for cloud services.
In general, developing applications for deployment in the cloud is really no different than developing applications for deployment locally. The tricky part of developing for the cloud, whether private or public, is the introduction of load balancing or application delivery into the equation. Many applications that were never seen as needing the scalability services provided by these solutions will necessarily, due to architecture and function, interact with these solutions in the cloud. The same issues that often arise in local deployments requiring load balancing or application delivery services will arise in the cloud.
Being aware of what those issues are and addressing them up front, if possible, is the best way to minimize the potential impact of an on-demand environment on the behavior and execution of applications in the cloud.