I'm using a website, abc.com, that is hosting an iframe of a page on 123.com.
The page inside the iframe is doing an AJAX request to another page on 123.com, but we're seeing that the request is getting cancelled.
Unless I'm wrong — and I haven't found any official information on the internet about this — the call should work fine as it is not a cross-domain request.
Would the fact that the parent frame is on a different domain really hinder the iframe from doing AJAX requests to its own server?
The IFRAME should be able to make an ajax request to its own originating site (same source URL). However, make sure the REQUEST event is FIRED from the IFRAME, not the parent.
My first guess would be you are loading the IFRAME and then addressing it (firing an event) via the parent (JS) to get it to do/get/set something which triggers an ajax call. In short, this is the mostly likely reason the IFRAME domain to same domain request is getting cancelled as it is still recognized by the browser as originating from outside the target domain code.
The REQUEST event needs to be organically generated from the user clicking on something in the IFRAME or from code in the IFRAME itself firing the event.
In other words: just because the IFRAME may have some ability to fire events/ajax in its JS/code to/from itself, it would normally still not be allowed to have the parent reference that ajax/JS directly via JS/code. The IFRAME has to already be coded to do it based on its load parameters (URL values, perhaps) or the user has to physically click/take action on something to create a user generated event on that domain.
Of course, this is going to vary a bit by browser and version on what you might be able coax in terms interactivity between the parent and iframe. But a strict, up-to-date browser will try to keep you from faking insecure interaction on the iFrame via js.
To get a better answer, you would need to provide more detail on exactly what you are doing/getting.
Related
I just started studying Ajax and I totally have not idea what AJAX is. What is the difference between asynchronous and synchronous request? I would like to seek a very simple example demonstrating their differences.
AJAX short for Asynchronous JavaScript And XML is a programming language. It typically involves sending HTTP requests from client to server and processing the server's response, without reloading the entire page. This process is asynchronous. Comparing to synchronous request which blocks the client until operation completes, asynchronous HTTP is more efficient and user-friendly.
Take very simple example, when you are signing up on a commercial website, you can know whether your username is available or not once you finish typing the name. If the username was used already, the website will give you a reminder that your username is used on the same web page. This is the application of AJAX, so you don't need to complete the whole form and click the submit button to know that your username is not available.
AJAX uses two components for request process and display:
A browser built-in XMLHttpRequest object (to request data from a web server)
JavaScript and HTML DOM (to display or use the data)
It begins with an event occurs in a web page, such as a button is clicked. Then an XMLHttpRequest object is created by JavaScript, followed by sending a request to a web server. Once the web server receives the request, it will process it and send a response back to the web page. Then the webpage utilizes JavaScript to perform update of the web page without reloading the whole page.
AJAX stands for Asynchronous JavaScript And XML
Ajax main purpose is the loading data from the server without refreshing the web page
It's works in the background thread without interrupting UI thread
AJAX allows web pages to be updated asynchronously by exchanging data with a web server behind the scenes. This means that it is possible to update parts of a web page, without reloading the whole page.
A browser built-in XMLHttpRequest object which is used to request data from a web server
Example
when you are filling any kind of online form that time observe one thing there is option for country,state,district.
In this country drop down initially filled with data but state and district's are empty.
when you select a country like India then Asynchronous call goes to server and fetch the data of state drop down respective to selected country and so on.
when AJAX request fetching the data for the state drop down you are eligible to work with other parts of the form.
Many (probably the majority) of AJAX calls are done by a browser on a webpage and that webpage has a URL. Is it possible for a webserver to that's receiving the AJAX request to determine the URL of the webpage where the AJAX call was made? I assume there isn't a standard that requires this data in the headers, but perhaps some browsers include that info? Obviously this doesn't apply if the AJAX call was made from a phone app or other application without a URL.
Very generically (though unreliable), check incoming request headers for Referer. That should give you information about the source page.
Just keep in mind it can be spoofed, absent, etc. and shouldn't be considered bullet-proof (though it doesn't sound like you need it to be anyways).
I'm working on a Facebook Canvas App, and which by definition loads the code/webpage for my app in an iFrame on the Facebook website.
During development I have got the impression that if I make an AJAX request from my App's webpage to a webservice for my app which is on exactly the same server/domain name as the webpage, that that is actually technically a cross domain request - because the page originally loaded in the (top) frame of the browser is on a different domain to my webservice.
However I now believe that, due perhaps to a bug in my code, I was mistaken, and a page in an iFrame can make requests to URLs on the same domain as it without being a cross domain requests.
Clarifying this is particularly important to me as I now believe I can actually use POST requests instead of having to use JSONP GET requests.
If someone could clarify this for me I would greatly appreciate it. I have search around and cannot find a clear statement on this scenario.
EDIT: To provide more clarification: my Facebook App page URL at https://apps.facebook.com/myapp/ loads my webpage at www.mydomain.com in an iFrame. The webpage at www.mydomain.com then makes an AJAX request to a webservice on www.mydomain.com (at eg. www.mydomain.com/webservice/). So is the request from my webpage to my webservice a Cross Domain request or not?
Cheers
Matt
Your document loaded within the iframe is still a document of it’s own, and behaves like any other document, whether it be displayed in a frame or not, when it comes to the same origin policy.
So yes, you can absolutely make AJAX requests to the domain that your document got delivered from, not matter that it is displayed inside an iframe on Facebook.com.
There is no crossing of domain boundaries involved.
Is it possible to write and create a JavaScript Ajax request witch cannot be catched by the Firebug plugin in Firefox?
I'm asking this because I can see on Facebook that there are no Ajax request going on, but still when I sent a message from another Account, the message box on the top will add the "1 unread message" indicator... How's even this possible to achive?
Thanks.
Firebug logs "standard" AJAX requests to the Console panel; these are requests initiated using ActiveX/XHR.
Other types of requests are happening, though - CSS loading, images, javascript, etc. These requests are logged in Firebug's Net panel. Note also that requests logged in Console also appear in Net.
JSONP is a cross-domain method of AJAX in which a <script> tag is added to the page. When the request completes, the loaded contents of the script tag are parsed as JSON. The reason this works is that you are "tricking" your browser into treating the request as a request for a javascript resource rather than an AJAX request, thus skirting cross-browser security restrictions.
Putting this all together, JSONP requests (as well as all other types of requests, listed here as well as all <iframe> requests) are logged on the Net panel rather than in the Console panel. This isn't a bug or a problem; understanding the way JSONP works it is logical that the request would only appear in Net.
When using jsonp as your data type your calls do not show up in Firebug.
Firstly, I have to admit I am new to Magento and PHP. I am writing the configuration for my custom module. I would like to allow entry of some information, then send that information to a servlet on my web server where it is processed and a response returned and displayed in the configuration gui in a read-only field.
I am getting my guidance from various web articles and by looking at other modules' code. A module that does something similar is the PayPal module. However, it brings up a new browser window where the user logs in and enters their details. I just want to send the data gathered and wait for the response.
In my system.xml file I specify a frontend_model. In that frontend_model, the _prepareLayout method sets the template to my template, and in that template I have an HTML button. I added an onClick event handler to that button which makes an AJAX call to my web site. Unsurprisingly (because of the same origin policy I assume) the AJAX call fails with a code of 0.
I guess what I should be doing is when the user clicks the button, the request including the data they have entered in the other fields, is sent to the Magento server, and the AJAX call to my web site is made from there? Or perhaps my approach is completely wrong and there is a more appropriate way to achieve this?
Thank you.
You're right about the same origin policy. The best approach here would be to have the button trigger an ajax call to a local magento based controller, which itself uses curl or some other http request library to forward on a request to your remote servlet and process the feedback.
Try searching here "JSONP" or google the same thing. Dependent of javascript library you are using there are pre-made components/plugins to achieve what you are after.