Re: Client IP question

I'm assuming you're providing some kind of endpoint that webmasters (your clients) can link to/embed/whatever in their web pages. These typically work as follows: when your customer subscribes to your service, you provide some string that identifies their application. If you've ever used any commercial web analytics service, it's very similar.

Perhaps you provide the customer something like this to embed in their webpage:

<script src="http://example.com/my_cool_javascript.pl?id=abc1234"></script>

...where that "abc1234" can be any string that your business uses to uniquely identify its customers.
You would have to make it so that this value is also included in any other web requests that this javascript might make.
When/if a customer's subscription expires, my_cool_javascript.pl will stop serving the javascript that it once did. You would need to devise some way of checking if a customer still has a subscription to your service.

-Thomas
"Excuse me for butting in, but I'm interrupt-driven..."

Comment on Re: Client IP question

Replies are listed 'Best First'.
Re^2: Client IP question by kepler (Scribe) on Dec 22, 2015 at 01:36 UTC
Hi I thought about it and there's only one way - I think - to be sure that the domain calling the scripts is a certified one. HTTP_HOST in Perl gives my host name. But in Javascript or php, window.document.location.hostname or $_SERVER'HTTP_HOST' gives theirs... So if a request with one id matching a client domain is made and a javascript code is sent and compares the two values, I might prevent a hijack. If the hosts don't match, I make an automatic redirect. What do you think? Regards, Kepler	[reply]
Re^3: Client IP question by soonix (Canon) on Dec 22, 2015 at 15:02 UTC
JavaScript `document.location` sounds plausible, but PHP `$_SERVER['HTTP_HOST']` should give the same as Perl CGI's `$ENV{'HTTP_HOST'}`, because both should come from the (supposedly same) web server — or are you using client side PHP??	[reply] [d/l] [select]
Re^3: Client IP question by thomas895 (Deacon) on Dec 22, 2015 at 21:51 UTC
It's impossible to prevent your javascript from being copied to some other site and being used from there. In fact, it's also trivial to spoof everything so as to make your service think that the actual customer is making the request. If this is a problem, find a way to restructure your service such that the APIs are private - not for being called by your customers' customers. For an example, look at Google's OAuth flow. Perhaps this will work, perhaps not - you haven't told us much about what exactly it is you're trying to accomplish. -Thomas "Excuse me for butting in, but I'm interrupt-driven..."	[reply]
Re^4: Client IP question by kepler (Scribe) on Dec 23, 2015 at 11:33 UTC
Hi, I'm sorry for the late reply... Indeed you are right. The php variable doesn't work, and the javascript can be copied - but not altered. My doubt is if the javascript hostname variable can be tampered. Still, I'm thinking in the following: before my app script is called from my client's website, a file must be written in their website with the current date and id which is also stored in my website. When the main app script is called, I catch the referer and get from my client website the file. The values must check. The hacker can't - I think - write or modify this file in my client space - he also can't fake it because I'm getting my real customer pass text file... What do you guys think...? Regards, Kepler	[reply]
Re^5: Client IP question by thomas895 (Deacon) on Dec 24, 2015 at 01:29 UTC


Think about Loose Coupling
	PerlMonks