gwhite has asked for the wisdom of the Perl Monks concerning the following question:

I have some scripts hosted on my site that I am charging other sites a small subscription fee to access. The subscription model is working for me, since there is hardly any tech support, and the subscribing sites, basically add one HTML page to their site and they are good to go. Currently, the scripts will only accept data if the referrer variable is my site or one of the subscribed sites. (Yes, I know referrer can be spoofed, but daily graphs can show me sudden volume increases from a specific referrer). Browsers that use things like Norton Internet Security, some proxies etc, don't pass referrer, which mean some legitimate visitors don't get to use the scripts. Is there a better way to do this? I am running an Apache webserver if that helps formulate a solution.

g_White

  • Comment on Referrer not good, but anything better?

Replies are listed 'Best First'.
Re: Referrer not good, but anything better?
by sauoq (Abbot) on Dec 30, 2002 at 17:07 UTC

    Require your subscribing sites to proxy requests to your site and then base your access control and billing on IP. It is more difficult to set up but it is more robust too.

    -sauoq
"My two cents aren't worth a dime.";
[reply]
      A good suggestion - you could even supply a ready-to-run CGI script that does the job. Of course, it does limit you to sites that can run CGIs or otherwise have control over their webserver.

      Makeshifts last the longest.

[reply]
Re: Referrer not good, but anything better?
by adrianh (Chancellor) on Dec 30, 2002 at 17:18 UTC

    If you want the setup for the subscribing sites to remain simple then I think that referrer is probably you're best bet.

    If you can make it more complicated then the solution would be to get their server to fetch the page, or a token that allowed access to the page.

    For example:

    • Rather than linking to your pages directly get their server to proxy requests to your server - then you can track their proxies IP directly.
    • Rather than redirect to your page directly, get a CGI on their server to request a URL from a CGI on your site (which will expire after an appropriate period). They can then redirect to this temporary URL and you can track requests to the url-giver CGI on your site from their server.
[reply]
Re: Referrer not good, but anything better?
by traveler (Parson) on Dec 30, 2002 at 20:05 UTC
    I have done something somewhat similar to sauoq's suggestion: add 2 parameters to the url (e.g. gwhite.com?referrer=traveler.com?id=0949), then validate the "id" parameter with a request back to the referrer. The request needs to timeout on the "referrer". (I use an MD5 value for the id, and validation is a bit more complex, but the idea is similar.) If you are not too concerned about security, you could make the id be some function (e.g. MD5) of the referrer, perhaps the destination page, and a changing key such that it could be validated directly on your machine.

    HTH, --traveler

[reply]
[d/l]
Re: Referrer not good, but anything better?
by hardburn (Abbot) on Dec 30, 2002 at 17:17 UTC

    Instead of having them point directly to the scripts on your site, have them use an SSI exec that points to a script on their own server, which in turn pulls data off your own scripts. You can then verify the customer's access by their IP address.

    Though the proxy script could be really simple (basically, use LWP::UserAgent to pull the data through and print it to STDOUT), your customers might not want to turn on SSI execs.

[reply]
Re: Referrer not good, but anything better?
by John M. Dlugosz (Monsignor) on Dec 30, 2002 at 17:20 UTC
    Have your subscribers log-in formally before downloading their updates. Use the basic authentication built into Apache, for example. Just set up the .htaccess (is that the right name?) file to allow your customers. They will get a pop-up to give their correct customer name, regardless of their IP address.
[reply]
      Although this may seem like a solution it is almost always not -- in his service model, the sites that are paying for his services will almost never want to pass user:pass info to him for their customers. also a single user:pass does not bode well for security as third party subscribers would be able to use one of the "services" the site is offering after canceling there account. If you look at sites that do this often the 4 basic models used are:

      Transperant proxy / SSI(all requests come from subscribing sites)
      Referrer (auth is based on last url)
      Temp user/ID per request (cgi on the services box grants a user/pass via cgi that allows user temporary access)
      Domain level cookie (middle site creates a dns record for <service>.itsdomain.com that points to the subscribed service -- then creates a cookie in its domain for auth)


      -Waswas
[reply]

Back to Seekers of Perl Wisdom