Inclusion of external files . js

Asked

Viewed 168 times

2

Guys, I have a . js file in meudominio.com/.js file (example). This file contains functions that send requests via Ajax to another file, the.php data (does the search and returns in json), which is in the same folder as the .js. file hosting. js on pages located on another hosting and make a kind of api.

The problem is that when I include this . js it believes that the.php data is in the hosting of the file where I am including the . js, then the request fails because of this.

I wanted to know how to send the post to the hosting data where the . js is, and not the hosting of the file where I am including the.

Example of the request:

$.ajax({
method:"post",
url:"dados.php", <= aqui eu quero que ele busque o dados.php da hospedagem onde está o .js
...
})

It is possible to do this?

php javascript jquery html ajax

  • Let me get this straight. You want to make a POST request on a page that is outside your hosting, using PHP?

2 answers

2


The name of it is CORS. Browsers and servers by default block any request that has not come from the original server. You can configure your server so that it can accept requests from sites that it "knows" or from anywhere else.

If you don’t have access to server settings, you can force CORS by PHP, thus (note that all your PHP pages will need to execute this command).

0

Access-Control-Allow-Origin called a header CORS (Cross-Origin Resource Sharing).

When a site X tries to access the content of another site Y, the site that made the request (site X) can send a response header Access-Control-Allow-Origin to tell the browser that the content of this page is accessible to certain sources. By default, the pages of the site Y are not accessible to other sources; using the header Access-Control-Allow-Origin opens a door for cross origin access by specific requesting origins.

For every resource/page that Site Y wants to make accessible to Site X, Site Y must serve its pages with the response header:

Access-Control-Allow-Origin: http://siteX.com

Modern browsers will not block requests between domains. If Site X requests a page from Site Y, the browser will actually access the requested page and check the Site X response headers as an allowed requester domain. If Site Y has not indicated that Site X is permitted to access this page, the browser will trigger an error event on XMLHttpRequest and deny the applicant Javascript code response data.

Uncomplicated requests What happens at network level can be a little more complex than explained above. If the request is a request "nonsimple", the first browser sends a "pre-print" OPTIONS request, to verify that the server will accept the request. A request is considered "non-simple" when one (or both) situations:

  • Uses an HTTP method other than GET or POST (for example, PUT, DELETE)

  • Uses "non-simple" request headers; the only requests simple headers are:

    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type (this is only simple when its value is application / x-www-form-urlencoded, multipart/form-data, or text/plain)

Whether the server responds to verification options with appropriate response headers (Control-Allow-Headers for "non-simple" headers and Access-Access-Control-Allow-Methods for "non-simple") methods that correspond to the "non-simple" method and/or "non-simple" headers, then the browser sends the actual request.

Assuming Site X wants to submit a PUT request to /SomePage, with a value Content-Type nonsimple of application/json, the browser first send a proof request:

OPTIONS /SomePage HTTP/1.1
Origin: http://siteX.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

Note that Access-Control-Request-Method and Access-Control-Request-Headers are added by the browser automatically; you do not need to add them. This OPTIONS proof gets the successful response headers:

Access-Control-Allow-Origin: http://siteX.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

When submitting the actual request (after the proof is made), the behavior is identical to how a simple request is handled. In other words, a "non-simple" request, the proof of which is successful, is handled in the same way as a simple request (i.e., the server must still send Access-Control-Allow-Origin back to the real answer).

Browsers send the actual request:

PUT /SomePage HTTP/1.1
Origin: http://siteX.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

And the server sends back a Access-Control-Allow-Origin, the same way you would for a simple request:

Access-Control-Allow-Origin: http://siteX.com

Behold Xmlhttprequest Understanding about CORS for a little more information on the non-transparent orders.

Source: apsillers

Browser other questions tagged php javascript jquery html ajax

You are not signed in. Login or sign up in order to post.