in reply to How to reliably get referrer?

You could pass on a dynamically (server-side) generated and logged token from site A to site B (for instance, as a GET parameter), then you can check the tokens later to see if they match. Or better yet, use some kind of inter-server mechanism (like memcached) to check the token when the request reaches site B.

Without some dynamic serverside control of server A, you won't be able to get even remotely reliable prevention of spoofing.

updated for clarification

Replies are listed 'Best First'.
Re^2: How to reliably get referrer?
by punch_card_don (Curate) on Mar 03, 2009 at 15:28 UTC
    Ya, that sounds like the best idea yet. It'll add a step - htaccess redirects to a local Perl script, which generates a hash from a private key and redirects to the remote Perl script, which checks the hash against the same private key, and, if OK, does its logging and redirects back to the originally requested file. Do-able.

    But, how to make that happen as a GET so it doesn't all show up in the location bar? I was thinking redirects by printing location headers, but that'll put the info in the url.

    Update - uh, I mean the opposite - instead of redirecting as a GET, it'd be nice to be able to redirect as a POST so that the info won't show up in the location bar.

    Update 2 - hmmm, maybe less do-able than I thought - because of course when the last Perl script redirects to the desired file, htaccess will test the referer again. If I'm appending a dynamically generated hash, it won't match whatever url htaccess has been statically programmed to test against, and if I append a static key, then all it takes is one successful visit to the page and the user can circumvent the system by re-inputting that url. Hmmmmm.....