Well you have to decide how you are going to determine if they are from the appropriate place. You have a couple of choices:

1. Check the REMOTE_ADDR environment variable (set by standard CGI and mod_perl, there are other ways to get it for different web apps), do a reverse look up on it and check the domain
2. Have some token they use to ID which discount applies then either keep it as a hidden on all pages, store it on the server side session info for the user or set a cookie

Choice 1, relying on the DNS name:

use Socket;

my $remote_addr = $ENV{REMOTE_ADDR};
my $remote_host =
    gethostbyaddr(itet_aton($remote_addr), AF_INET);

if ($remote_host =~ /\.oracle\.com$/) {
   # Do whatever
}
[download]

Implementing choice 2 is up to you since it is very dependent on the code you are using.

The advantage of the first is that there is not much you have to do to get it to work since the hostname should not change over the course of the transaction. With the second you have to store the token somewhere so that you can access it on each request. Depending on the infrastructure you have in place, that may be easy.

Where the second choice wins is that it is possible that not all IP addresses have a reverse lookup even if they are all in Oracle's domain. Also people may be accessing Oracle mail through a VPN so the discount would not apply to them. If you have a special token then this does not matter since the token applies no matter where they come from. Also you can use the same mechanism for promotional purposes where you issue a discount 'coupon' if they do something. The obvious downside is that people can mail the tokens around so other people may get the discount.

-ben

One of the cuter variations on this was a company a few years back that checked $ENV{'REMOTE_ADDR'} for incoming requests to their home page, and spit back a special "We're Hiring" page for requests that came from competitors.

A couple of things:
1. REMOTE_ADDR and REMOTE_HOST can be modified by the user. There is no guarantee that the value transmitted for these variables is correct. Therefor, these can be abused by someone attempting to gain improper discounts.
2. Storing an ID as a hidden on a page again leaves you open for abuse. This relates strongly to the recent rash of poorly written shopping cart systems being abused. The prices were being "hidden" in the HTML, all a would be abuser needed to do was: Save the HTML, change the price, hit the button -- Wallah! Pay $1.00 for a $100.00 item. Storing an ID for discount could be similarly abused.
3. Storing ID in a cookie, should be combined with sessioning to help avoid abuse. If the cookie value is indexed in such a way that it is only good for a period of time, the chance for abuse is limited. Possibly linked to IP or other identifying information as well, to make transference of the cookie ID to a different machine more problematic. This type of solution will probably lead you to have to "re-authenticate" the user periodically based on some business rules regarding latentcy and/or total visit time.
Please do not fall into the trap of believing a piece of sensitive data in a "HIDDEN" form field is secure or tamper-proof -- it simply is not, and has been abused significantly, regularly, and recently.

Good points. I guess I should have mentioned more about security of each method.

REMOTE_ADDR and REMOTE_HOST are pretty safe since they come from the sockaddr struct that relates to the connection, so you are somewhat succeptible to a man-in-the-middle attack if the sender can spoof the IP address and catch the return packets (assuming that there is no TCP sequence number bug that allows him to predict the excact set of packets to send from elsewhere). Of course you are succeptible to a DNS attack if the attacker can spoof the reverse IP address lookup, and DNS is notoriously unsafe.

Storing the ID on each page is relatively safe iff (sic) the discount ID refers to a token ID stored in the DB that is generated randomly (assuming your random number generator is sufficiently random) from a large search space. Really cookies and hidden form variables are equivalent since they are both submitted on each request and the user can munge them both. Since this is discounts you have to decide if you want the user to log in to the site.

Personally I despise logging in until I am actually ready to order. It might be more productive for a site to give a 5% discount to a handful more people if they get more sales in general. Remember that stores often see 30 - 60% markups so they are making a profit even if they offer substantial discounts.

-ben