How do I block outside access to an online coupon on a Microsoft IIS webserver?

May 1, 2006 6:29 AM

I have a client that's just beginning to experiment with online coupons. We want to make it so that you can get to the coupon (currently a GIF image) through a specific link on his website, but if that link gets passed around (via email or IM, say) access will be blocked.

I've got a little experience blocking access to files and directories on an Apache server, but the site is being hosted on a Windows IIS box and I'm out of my element. At first we tried following the instructions listed here to try and filter requests by IP address, and it even worked for a little while, but then it started blocking all access no matter where the request came from.

I'd really love to solve this problem server-side, but If I needed to make the html wrapper for the coupon in .asp or .net we could do that.

posted by ssmith to computers & internet (9 comments total)

It's not foolproof, but you can check the referer. (some .asp info)
posted by the jam at 6:35 AM on May 1, 2006

Also, if you have control of the referring page, you could set a session cookie with a signed key -- like md5(user-agent + host-ip + secret) -- that you could verify on the coupon page.
posted by the jam at 6:38 AM on May 1, 2006

What would stop people from simply emailing the .gif itself in this scenario?
posted by jacquilynne at 7:16 AM on May 1, 2006

It's not easy to be 100% secure. First, you have to accept that once ONE person has downloaded the image, that graphic itself can be passed around, so you will never have complete protection.

Best protection is if you can personalize the coupon with recipient name and address, and some sort of unique ID or PIN that can be checked later when the coupon is redeemed. You can do that by generating the coupon on the fly using a server-side PDF generator, or some other graphic processor. But then you have costs on the redemption end.

Straight personalization will help, but can be spoofed with Photoshop/GIMP.

In any case, the coupon image should be served by an application that looks for a session or cookie set after a successful registration/log-in/whatever. You can also put limits on how long the user has to download the coupon, or how many tries.
posted by Artful Codger at 7:22 AM on May 1, 2006

Yeah, having the graphic passed around is a pretty gargantuan hole in the system. But that's a battle we know we'd lose.

We realize that there's pretty much no way to make the coupon protection system completely airtight to a savvy web user - much less a dedicated one. We just want to plug as many holes as we can.

Thank you for the responses so far!
posted by ssmith at 8:20 AM on May 1, 2006

How about requiring the user to give, say, an e-mail address in order to get the coupon (shoot, you could e-mail the coupon rather than display it on the website), and embedding a numeric hash of the address in the image?

If you keep a log of the hashes issued, that would solve the re-use issue. And I think the overhead for doing this would be pretty low—MD5 is a single operation in PHP, and Imagemagick is perfect for overlaying the text.

Thinking about this further, you don't actually need the coupon image at all: just e-mail the hashed value and call that the coupon. Have the customer print out the e-mail they receive, and that is their coupon. If the coupon is being presented in person, the staff would need to check A) that the e-mail address matches the hash, and B) that the hash hasn't been used. Which may not be feasible. Then again, you'd just need a printout showing a list of e-mail addresses & corresponding hashes, and cross them off the list as they come in.
posted by adamrice at 8:28 AM on May 1, 2006

Following up on adamrice's suggestion, if you simply generate a number that's unique for each person such that people think it's unique and only usable once they'll be less inclined to send it around if they want to use it themselves.

So if you can generate the semi-unique number on the fly and use a barcode font to put a barcode on each coupon you might be able to use social engineering to solve this problem. If you're not storing and retrieving the number it doesn't even need to be a real value. Just use one of ASP's functions for generating GUIDs and use that.
posted by phearlez at 8:53 AM on May 1, 2006

Unless the coupon can be redeemed to get something for free, why are they worried about the GIF being passed around? It's free marketing, more visitors to their web site. Isn't that good? Why put up roadblocks between potential customers and their product?

If too many people are redeeming the coupon, it would seem to indicate demand, so just raise the price a little.
posted by ldenneau at 11:52 AM on May 1, 2006

You make a good point Idenneau, and I've tried that same exact argument over and over. Sometimes you just have to let the "clients always be right" once in a while. This is just their first try offering something like this online so they're a little nervous.

Thanks for the responses everybody.
posted by ssmith at 1:28 PM on May 1, 2006