Access Control

[thudfactor]

Hey, folks -- I have a problem with access control on web pages; maybe someone here can help out. This is the way it works (briefly):

I have a page on Server A with a link to a page on Server B. I want the page on server B served ONLY if it came as a result from a request from the page on Server A. The tools at my disposal: I can edit HTML on server A. I am root on Server B, which is a linux server running Apache with PHP4 in place.

I was hoping to avoid dependence on browsers -- like checking REFERRER values that might be blocked by people running ad blocking software, etc. Our audience is international AND academic, so I can anticipate a wide range of browsers and a lot of security-concious people. What are my options?

Thanks!

[manish]

Why don't you use a .htaccess file in the directory you need to protect on server B. Here's an example:


AuthType Basic
order deny,allow
deny from all
allow from 192.168.0.1
allow from servera.com


Manish

[thudfactor]

But wouldn't that just allow server A to talk to server B? Actually, now that I look at it, that is the question I asked.

Actually, what I meant was: the page on server B won't be served unless that page was called by a link, form, whatever from server A. Will the .htaccess file achieve that? I thought if the page was called via a link, the "allow from" clause would check the IP/DN of the the computer the browser resides on, not the IP/DN of the page with the link....

[sheila]

Well, you could write some sort of script that would check for the environment variable HTTP_REFERER and see if it is the link from your site or not. The problem with that, is some people have their browsers set up to not give that information.

Instead you could write a script that checked for the IP address in the environment variable REMOTE_ADDR and see if it matches the IP address from Server A.

I think you are right about the .htaccess. It would block people from your site, even though they got their by following your link.

The "script" for environment variable checking could probably be done in JavaScript, but its possible you would have browser compatibility issues there. I just am really shy of Javascript for that reason.

Perl, Python or PHP would handle this task nicely. Actually, PHP would probably be easiest (if you have access to that on Server B). You could set it up so it displays one page if the REMOTE_ADDR is the correct IP address, or a different page otherwise.

<added later>

Ack! No, I'm wrong there. The REMOTE_ADDR is the IP number of your site's visitor's computer.

Not thinking clearly this early in the morning (not yet 8 am here).

I guess HTTP_REFERER is your best bet, and then you have to decide how you want to handle requests that don't give the referer. Do you want to let them see the page anyway, or refuse them?

</added later>

[Arthur]

If you only have HTML on server A it's gonna be very difficult. The only -unreliable- way would be using the referrer field as Sheila pointed out.

If you had something more on server A, like PHP, or PHP and a database, then you have some more options.
You could make a kind of "ticket" system. When the user visits server A, he/she is redirected to server B with a URL that includes a unique identifier/ticket.
This indentifier/ticket could be the IP address of the user encoded with the time with some algorithm you write. Server B knows how to decode the identifier/ticket to check the validity.

The ticket could also be something random, but then it has to be stored on server A, so that if the user contacts server B, server B checks with server A to ask if server A issued that ticket. This way, the ticket doesn't even have to be in the URL.

Arthur

[sheila]

Interesting idea, arthur, but you lost me here:
Originally posted by arthur:

The ticket could also be something random, but then it has to be stored on server A, so that if the user contacts server B, server B checks with server A to ask if server A issued that ticket. This way, the ticket doesn't even have to be in the URL.
Where would the ticket issued from server A be if it were not in the URL? In a cookie? (Actually, you could probably do this whole thing with cookies, too, except some people may not have cookies enabled. Still, I was thinking of doing some things with cookies on my site...been considering this for a while...and it seems to me you can't do much web browsing if you don't accept cookies these days.)

Or are you saying that Server A would store the ticket in some database/file and then Server B would look it up there?

Actually, you could do this:
Just log the recent visits by IP number on server A, with a time stamp. When server B gets a request, it looks to see if the visitor's IP address is listed in the log of recent visitors to site A. That might even be the easiest. Avoids the whole encoding/decoding thing.

[Arthur]

Server A would store the ticket in some database/file and then Server B would look it up there? That's right, ticket isn't the right word in that case, it would would just be a log of the time the user with IP x.x.x.x visited. Which you can do through the standard web logs, as per your suggestion.

[thudfactor]

Thanks, folks. Yeah, it looks like it'll be difficult to do what I'm trying to do without using the referrer variable. I guess I'm just going to have to instruct those (few) people who have turned that off in their browser to turn it on. They're accessing the page through a members-only site anyway, so they shouldn't (logically) be too bothered by that.

I do have PHP on server B, but server A is running a mish-mash of proprietary tools which I don't have real access to (hence: server B, which is entirely under my control...).

OK, so I'll use the referer option then in an .htaccess file. I actually have tested that out now, and it's working nicely. Thanks for your help!

-- J