Relying on the protocol or not
When it first started, we didn't ask that question to ourselves as to know if we could rely on specific HTTP server variables when a request was sent to a Web server. It was automatic and we were able to benefit of specific data as is being sure it was accurate. However, the introduction of specific options available for customization in browsers and the addition of specific tools that can be installed on a PC, this is no longer totally accurate.
In the first part of this article, we will discuss about the following HTTP fields:
REMOTE_ADDR
Many Web developers are making use of the REMOTE_ADDR variable to collect the IP of origin of the transaction. Despite the fact that in many occasions, this could represent the actual IP of the PC which has launched the transaction, in several cases, it won't be. Note that it is always good to track it for monitoring purposes as it would represent at least one point along the route which was used to submit the transaction and could lead, after investigation, to the IP of origin.
Take the example of a corporate infrastructure well established under a firewall. That would mean any IP received from any transaction from that corporation would be the one that the firewall has been configured to use. So, you would end up with the same IP coming in from various employees of that company.
Our next example are users using a proxy service from their ISP in order to hide their IP. That is a practice that is commonly used now for people known as troublemakers, hackers and related terminologies. Basically, their ISP could allow them to benefit of a specific proxy and whenever they will send a transaction, the IP received would be the one from that specific proxy. Note that the same approach could be used assuming someone would own his own proxy either individually or within a corporate environment.
So, there shouldn't be any assumption that this could represent the IP of origin even if you know that this is a user that is usually working from home within one single PC connected to the Internet.
One more example of such situation is when people are connected to a VPN connection and using that connection to access a specific Web site. Within a VPN connection, several users can connect to a server and this could add to the confusion of the IP received. Some users would want to use a VPN connection, assuming they would benefit of a stronger bandwidth ability, to hide again their IP of origin or to simply to some tests when being connected to such environment.
So, those are various scenarios that it might be good to collect the IP for specific validations and monitoring purposes, but what you collect is not exactly what you get.
HTTP_REFERER
The HTTP_REFERER server variable is another variable being used for many purposes. This variable returns the original URL when a redirect has occurred. This is a general definition used for this variable but it is more like the URL which was previously loaded in the same window environment.
But, no matter its definition, this is probably one of the most confused cause of problems for Web developers. The way this works and the interference caused by several third party tools is making this variable practically useless.
First of all, if a user types directly into the browser URL, you will receive a blank value for that variable, even if he was previously on a page from your site. The only time you can get a value is when the transaction is launched from the content of the page itself.
But, that is true as long as the transaction is being refreshed within the same window. That means if you have a Javascript that generates the transaction to be opened in a new window, you will also get a blank value as this server variable will exist only from within the same window.
But, the biggest cause of problems when making use of that value and a big percentage of support issues that needs to be supported is when the user is using a tool such as Zone Alarm Pro or Norton Internet Security which allows the user to enable specific privacy features. Basically, those tools sit between the browser and what is being sent to the server. That means, the browser relies on a protocol to send specific material but this is not what reaches the server.
So, if your application relies on the HTTP_REFERER variable for specific validation or related topics, you might soon have to support those users who will simply don't understand why it doesn't work for them. It's not that they wanted to do that specifically on your Web site, but the fact that they enabled that privacy option in a tool such as mentioned above, will auto default the same setting everywhere they go on the Internet. So, as they don't realize that specific Web applications might need that server variable to remain untouched, they will find themselves in such a situation soon or later.
Once discovered, either from the support issue or from their own knowledge of the situation, they usually can adjust that setting with a sub setting that will allow them to open a gate for specific Web site where this privacy option will not apply.
So, as it is the case of REMOTE_ADDR, I would only recommend the use of that variable for adding additional data to your audit files but not to rely on it in your application.
HTTP_COOKIE
The HTTP_COOKIE server variable is widely used on the Internet. This variable returns the cookie string included with the request. What many would consider as the first fear of the Internet, when browsing to several servers, it was causing more problems a few years ago than today.
Originally supported by several browsers at first, users are able to disable the cookie functionality by one simple click. Additionally to that, you will now find additional tools which would support that ability as well.
So, if your application relies on this server variable, make sure it is well known to your users that this is a requirement. Include it in your technical guidelines and elsewhere, if you wish, such as where the user is authenticating.
Opening new windows
This is, from my POV, the most serious issue right now that Web developers have to support in their application. Because of the SPAM revolution, all kind of tools have seen the light of day to counter attach any types of approaches that some specific Web site will use to SPAM their users.
The biggest problem, and caused by a bad perception of those who build those tools, are the fact that by default, they consider any new window to be opened as a SPAM. For example, whenever I go to ESPN to check sports results, I always have this big Orbitz advertising window which takes about the entire width in 1024 resolution and about 1/3 in height. This has been the case since a few months. I understand this is probably the biggest advertising vendor at ESPN and they are paying big money to benefit of that, but it is getting extremely annoying for users.
For big companies that already rely on another structure to bring money in, it is more frustrating that they are using such practice online as well. And, this is used widely by many companies across the Internet. The bigger their company, the bigger the amount of advertisement you will receive when navigating to their Web site.
But, not all new opened windows are advertisement. And, this is where the big problem is. You build a desktop application, have an invoicing form to build the invoice, and the first field the user has to select is the client ID. To collect the client ID, the user will probably click on an icon next to the field to launch a pick list. He selects a client by searching for it, sorting and filtering and now has the client ID in the base form. Why the same approach would be bad on the Internet? It isn't. But, the perception of those who builds such tools are creating a perception which auto-defaults to remove any new opened window to be disabled when the related no advertisement option is turned on.
Here is a new window that we are opening on the Universal Thread for selecting a member:
So, as you can see, this is totally not related to an advertisement. It is a pick list used to select a member and probably the best approach you could use for the related need.
But, for users using a tool which allows them to disable new windows, this creates a scenario, when this setting is turned on, that the user will click on a specific link on your site and nothing will ever happen. So, the user, in most cases, will think your Web site is not properly working. In many scenarios, he will not contact you assuming it would be fix soon. But, after having been frustrated at several occasions, you will then receive an email. The situation would be adjusted as to user, making use of such tool, can usually apply a filtering setting in order to have this new windows to work on your site.
The following are popular tools which support such ability:
So, again, a proper documentation on your Web site will help so is any additional ways of letting your users know about that requirement.
