I have a web site with following functionality: An user es to www.mysite/page.php
. Javascript on that page makes ajax API call to www.mysite/api.php
and shows results on the same page www.mysite/page.php
I'm afraid of situation where somebody starts to use my api.php on own software, because using www.mysite/api.php
costs me a bit money. Therefore I want that only users that have visited the page www.mysite/page.php
can get valid results from www.mysite/api.php
. There won't be any way for users to log in to my web site.
What would be the right way to do this? I guess I could start a session when an user es to page.php and then somehow maybe first check on api.php that a session with valid session id exists?
I have a web site with following functionality: An user es to www.mysite./page.php
. Javascript on that page makes ajax API call to www.mysite./api.php
and shows results on the same page www.mysite./page.php
I'm afraid of situation where somebody starts to use my api.php on own software, because using www.mysite./api.php
costs me a bit money. Therefore I want that only users that have visited the page www.mysite./page.php
can get valid results from www.mysite./api.php
. There won't be any way for users to log in to my web site.
What would be the right way to do this? I guess I could start a session when an user es to page.php and then somehow maybe first check on api.php that a session with valid session id exists?
Share Improve this question edited Dec 5, 2014 at 17:27 plsgogame 1,34415 silver badges28 bronze badges asked Dec 5, 2014 at 17:04 PetriPetri 1252 silver badges7 bronze badges 2- The big question is how would you distinguish robots vs. humans. Writing a robot who'd first "visit" your web site and then use the retrieved session id/token/whatever to access your API is not very hard. – lexicore Commented Dec 5, 2014 at 17:19
- Thanks everyone for quick replies! Even though there is no 100% protection agains everything, the PHP session probably is the best "soft" protection for this kind of case. – Petri Commented Dec 5, 2014 at 17:52
5 Answers
Reset to default 1If you just want the user to visit page.php before using api.php, the session is the way to go.
Typically, if you want a "soft" protection you use the POST verb to get results from your site. Then, if the user goes the the URL in their browser and just types the api.php call they will not get a result. This doesn't protect your site but it keeps search engines away from that url reasonably well and accidental browsing to it.
Otherwise, there are lots of authentication plugins for php.
http://www.homeandlearn.co.uk/php/php14p1.html for example.
You can check the request in several ways such as Token validation, Session validation or even by Server 'HTTP_REFERER' variable
Check the referrer with $_SERVER['HTTP_REFERER'] if its outside the domain block it.
Beware that people can alter their REFERER so its not secure.
Another better solution might be a CAPTCHA like this one from google https://www.google./recaptcha/intro/index.html
Cookies, HTTP-Referer, additional POST-Data or some form data, that you send in an hidden input field aren't secure enough to be sure, that the user es from your site.
Everything of it can be easily changed by user, by modifying the http-headerdata (or if you use cookies, by changing the cookie-file on the client machine).
I would prefer the PHP-Session bined with an good protection against bots (ex. a Honeypot), because it's not so easy to hi-jack, if you use them properly.
Please note: If there is a bot especially for your site, you lost anyway. So there isn't a 100% protection.