(For php developers): How to get client url for an ajax request?

marked

New member
OK, so I have created a CORS supported (meaning it can be accessed from anywhere with any domain) ajax server in php. Thing is, I want to enable my server for all domains except a few. I do not want to discriminate on the basis of IP address(es) but on the basis of domain names.

Is there a way I can get the url of the page which sends me (server) the ajax request? Note that the communication protocol has already been implemented and I cannot edit it. I posted a question about it on stack overflow http://stackoverflow.com/questions/33644675/client-url-during-ajax and they recommended using $_SERVER['HTTP_REFERER'] which is not working (probably because the user did not click on a link leading to the page).

Any help from you gurus? :S
 

keltron

New member
You can implements some control via .htaccess, in example

Code:
order deny,allow
deny from all
allow from 111.222.333.444

or eventually use get_headers ( ... ) PHP function to discriminate via headers.
 

marked

New member
I don't want to discriminate w.r.t. IP addresses, but w.r.t. domain names :(

How can the url of the requesting page be determined from the headers? :S
 

keltron

New member
with

Code:
apache_request_headers()['Referer'];

you can retrieve the request url. Using parse_url() you can get relevant data.

get_headers() is an alias to apache_request_headers() .

The problem is that not all requests have a referer, but if you've read about the CORS, than I think you know what i means.

I suppose in .htaccess you can use DNS instead IP.
 

fouadChk

Member
marked said:
OK, so I have created a CORS supported (meaning it can be accessed from anywhere with any domain) ajax server in php. Thing is, I want to enable my server for all domains except a few. I do not want to discriminate on the basis of IP address(es) but on the basis of domain names.

Is there a way I can get the url of the page which sends me (server) the ajax request? Note that the communication protocol has already been implemented and I cannot edit it. I posted a question about it on stack overflow http://stackoverflow.com/questions/33644...uring-ajax and they recommended using $_SERVER['HTTP_REFERER'] which is not working (probably because the user did not click on a link leading to the page).

Any help from you gurus? :S

Yes there is, by excluding those (banned) domains from accessing your COR's powered PHP script (or even the entire folder where it resides) based on the Origin header and not the referrer one (which might or might not be there.)

Browsers are compelled to send an Origin header with any COR request---in order to be compatible with the standard.

Thus my solution is this:
Code:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
#
## Banning_Domains__based__on__CORS_ origin_header
RewriteCond %{HTTP_ORIGIN} example1\.com [NC,OR]
RewriteCond %{HTTP_ORIGIN} example2\.com [NC,OR]
RewriteCond %{HTTP_ORIGIN} example3\.com [NC]
RewriteRule .* - [F]
</IfModule>

Note: This will work when it's done inside browsers. Outside the browser, with a simple adhoc script, that protection will fail (as in any other defense mechanism relying on the headers sent by clients.)

Good luck!
 

marked

New member
fouadChk said:
Yes there is, by excluding those (banned) domains from accessing your COR's powered PHP script (or even the entire folder where it resides) based on the Origin header and not the referrer one (which might or might not be there.)

Browsers are compelled to send an Origin header with any COR request---in order to be compatible with the standard.

Thus my solution is this:
Code:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
#
## Banning_Domains__based__on__CORS_ origin_header
RewriteCond %{HTTP_ORIGIN} example1\.com [NC,OR]
RewriteCond %{HTTP_ORIGIN} example2\.com [NC,OR]
RewriteCond %{HTTP_ORIGIN} example3\.com [NC]
RewriteRule .* - [F]
</IfModule>

Note: This will work when it's done inside browsers. Outside the browser, with a simple adhoc script, that protection will fail (as in any other defense mechanism relying on the headers sent by clients.)

Good luck!

What does the highlighted text mean? I did not understand that last bit properly.
 

fouadChk

Member
marked said:
fouadChk said:
Note: This will work when it's done inside browsers. Outside the browser, with a simple adhoc script, that protection will fail (as in any other defense mechanism relying on the headers sent by clients.)

What does the highlighted text mean? I did not understand that last bit properly.

That's just my usual heads up warning to remind people that HTTP requests aren't made by Web browsers only; any HTTP client can send them. It can be a standard browser or a command line tool that 'speaks HTTP' (wget, cURL etc....) or even a hand-crafted request made using any scripting language with HTTP support (PHP being one of them.)

Thus, if you are confident about browsers-compliance and know exactly what to expect from them, you should also be aware that you don't have those guaranties when it comes to those other HTTP client which mostly depend on the intent of their users---they send what they are told to and not what the standards impose/dictate.

That simple!