AOL makes my head hurt

[thudfactor]

OK, so here's a problem I'm hearing from a lot of AOL members of our site.

I'm passing people from Server A to Server B via a specific link. If someone from Server B has followed the correct link, then they get in. If someone has contacted Server B directly, they get a "denied access" message. Server B is checking the browser's REFERRER variable against an .htaccess file.

[Server B is not a futurequest server, unfortunately.]

People running some personal firewalls or ad blocking software can't seem to get in; but that's OK -- my Error 403 page tells them to turn that off for a moment, and since then I haven't heard a complaint. However, AOL people seem to be having problems seeing the pages. Calling AOL to get a clue is, as I understand it, a futile endeavor.

Anyone else face this before? Thanks!

[Justin]

I've always stressed that you cannot use user-input for security purposes. HTTP_REFERER is generated by the client, and is thus user-input. It can be modified/altered very easily, and is often (as your case proves) done without the user knowing it.

Plus, some Netscape versions sometimes just don't send a referer -- I don't know the reason, but I discovered this while trying to protect images using the referer. It's just not predictable enough for these purposes.

Asking users to "disable" some ad-blocking software or proxy server is an invite to press "Back", never to return... Some users aren't technical enough to know, and others are just put off by the notion that you don't trust them (whether or not that's the case, that's what it will seem like).

Can I ask -- what is the reason for this protection anyway? There's probably a better way to do whatever it is you're trying to accomplish...

[PaulKroll]

The firewall we have at work, a Novell one I believe, is set to wipe out all referrers. I don't know if it came set that way, but I know that's what it's doing now.

I would not be surprised if AOL did this for some odd reason. I would not be surprised if AOL, frankly, had a firewall/proxy that replaced every fourth letter "i" in requested URLs with the letter "e", for some reason that makes perfect sense to them. ("We're trying to prevent vowel misbalance, you see...")

[thudfactor]

Without a doubt there's a better way to do it than what I'm doing. Given proper resources this would be a trival task.

Here's the previous discussion about security options available to me:

http://www.aota.net/forums/showthread.php?s=&threadid=9341

[Justin]

I glanced at the other thread, and unfortunately there is no definitive answer. When you look at the information available, the only one involved who can say for sure who "referred" the user to Server B is the browser, which as we know won't work.

Tracking/comparing IPs won't work for users behind a proxy or cache, and is a major mess to sync between the two servers...

ID tracking might be used. Server A forms a special URL with a special ID attached to it, and Server B checks this ID against a list, only serving each ID once. This is how a lot of credit-card services work. But again, major work to pull this off, and I still don't know *what* you're accomplishing with this.

What is the reason you need to do this? Is it security-related, credit-card verification, or something else? I'm extremely curious why you would need such a requirement... my guess (and I don't mean anything personal) is that you're trying to use the web for something it wasn't built for... which is why there are no definitive tools in place for this level of verification...

[thudfactor]

my guess (and I don't mean anything personal) is that you're trying to use the web for something it wasn't built for

Hah. Well, you point me to a page that IS using the web for what it's built for. Precious little of the web is used for something it's not built for, which is why practically every web application is kludgy.

In this case, we have a membership only site. We don't WANT traffic coming from "anywhere," we want it coming from our member-only section. The server that does access control for us is not under our control, so there's precious little we can do there. Also, the server that does our hosting (being the same as the one that uses access control) does not have the tools we want to use (PHP, mySQL). For a variety of non-technical reasons, "reconfigure the server or else" is not an option, so we had to get another server. Also for non-technical reasons, we had to get the server outside of our normal procurement methods, system vetting, etc.

The result is: people have to log into server A (so membership records can be checked, etc), then be sent to server B to get the proprietary information we're offering. Since these people are already members, and we're not selling ad impressions, etc., we're not terribly concerned about a small number of people visiting the site never to return when they're offended by us suggesting they drop their ad-blocking software. We're also not very concerned about people hacking in. The security we're looking for on this is not lok-tite stuff, but more like a car-door lock. We want to dissuade casual abuse; we can deal with focused hackers in other ways.