I have a script that inject an Iframe to my page, In rare occasions the service is down and the Iframe content is a 404 page content.
Can I detect somehow that the response of a cross domain page ( in-iframe ) is 404?
The simple answer is "no," not without CORS or help on the server side. The whole point of the same-origin policy is that you can't get information about content served from somewhere else.
Try using a server-side script to make a HEAD request to the site in question and make sure it's up.
Another possible workaround: Find an image on their site, and try to load that first. When the image loads, load the iframe. If it fails to load after some period of time, you can assume the server's down, and show a custom "oops" message. May or may not work depending on what's actually going on with that server.
Related
I have been given an address with a basic HTML structure, it just has some numbers in it. I have tried doing it as an Iframe, if I create a simple HTML that does work fine, but in the page itself if i hover over the iframe it says that it refused the connection.
I have tried with AJAX, but it does give me a mixed content error, since my page where I want the content inserted is secure (https) and the page where the numbers are is not.
Is there any workaround I can do in this case?
Thank you in advance.
this is because of CORS(cross domain access) problem:
if you are accessing the URL on same domain there won't be any problem but if you accessing content of another domain there is security issue.
this is possible only by below concepts:
Enabling CORs - https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Image pinging concepts - limited to data size
JSONP
Using JavaScript/jQuery within a web page, I need to load a different page into an iframe. I am doing it by finding the iframe using jQuery, and setting its src property, thus:
iframe.src = url;
Which works in that it displays the page in the iframe, but I need to attach a couple of cookies to that request to get the correct info on the page, and I can't figure out how to do that.
In the spirit of trial and error I tried inserting this line before the above code:
$.cookie("MyCookieName", "MyCookieValue");
but in Fiddler I see no cookie attached to the request. All the documentation I can find about cookies tells me how to generally get & set the values, but doesn't help explain what I'm doing wrong.
For what it's worth, the page that I'm loading into the iframe is in the same domain as the page hosting this JavaScript code.
How do I attach cookies to that query?
How do I attach cookies to that query?
You can’t “attach” cookies to a simple HTTP request that the browser makes on his own.
For what it's worth, the page that I'm loading into the iframe is in the same domain as the page hosting this JavaScript code.
Then set the cookie for that domain the normal way – once it’s set, the browser will send it when requesting the iframe URL automatically.
I have an HTML page with an iframe included from a cross domain that doesn't belong to me.
I need to do some basic javascript modifications in the iframe (write value and fire up an event -> form processing).
Because of the same origin policy I'm not allowed to do this. However, I need to do it, so I'm searching for a workaround.
The solution is just important that I can run a script for myself. It is enough if it works in one browser and I don't need security for myself.
On my research I have found a lot of ways to break the same origin policy like document.location (in FF only with similar locations), JSONP/sendMessage (I need to be the owner of both domains) and so on, nothing that works with an iframe of a page that doesn't belong to me.
The only "workaround", if you can't make the other site include the relevant CORS headers, would be to fetch the iframe content server side and serve it as coming from your own domain.
The reason there isn't simpler workaround is due to why there is this same origin policy : to protect users.
I want to load an external website in an iframe. But faced issues due to Same-Origin-Same-domain policy. So for solving this I used the proxy solution in which we send our request to a proxy file (I wrote in java) and then it requests the server and return back the response. This is working perfectly fine.
But using this method all the pages are not correctly loaded into my iframe.
Currently I am working on localhost. The problem i am facing is there are some errors in fetching the page like:-
On fetching www.google.com i got these errors:-
GET http://localhost:8080/images/srpr/logo1w.png 404 (Not Found)
a.html:101 GET http://localhost:8080/extern_js/f/CgJlbhICaW4gACswRTgALCswWjgALCswDjgALCswFzgALCswPDgALCswUTgALCswCjgAmgICaGUsKzCYATgALCswFjgALCswGTgBLCswQTgALCswTTgALCswTjgALCswVDgALCswaTgALCswkAE4ACwrMJIBOAAsKzDVATgALCsw2AE4ACwrMBg4ACwrMCY4ACyAAlCQAnA/Q4V9Cbp7fuo.js 404 (Not Found)
These errors are coming because relative path has been specified in the webpage i am fetching (I guess). Am I right? If I am then how to correct these things so that such errors can be corrected.
After searching on net, I got a site which does this perfectly. Please checkout http://optimizely.com
The issue appears to be that if a site uses relative HREFs (relative to the domain/path that the site was loaded from), then your solution will cause problems because you've changed the apparent load domain/path to something else.
One possibility is for you to inject a tag into the right place in the page (in the <head> section) like this to properly set the base href:
<base href="http://www.google.com">
See this article for more info: http://www.drostdesigns.com/base-href-tag/
This solution is not foolproof though because if the site is already using a <base href="xxx"> tag, your may cause problems and if javascript code is doing manipulations based on the loaded domain/path, the base href won't fix that. Whether those issues matter or not will depend upon the particular page.
If the base href solution doesn't work, you might have to proxy all the other requests for resources too (images, ajax calls, etc...) so that everything destined for the other host, but requested from you is proxied appropriately. This would be more foolproof.
There is no way we can tell just by the description you've posted so far of the problem.. but if the answer is indeed as you have alluded to, then simply correct it -- whenever you get a relative link, make it a fully qualified one by prepending the domain from within your proxying script.
we have a site with Iframes pointing to dynamic Urls (by user input).
In case of a 404/500 or any other error, we want to replace the Iframe source with a different user friendly other URL.
For this we can use with the onerror event to identify when the dynamic websites have problems. (then, in case of problem replace the iframe url)
This works also for cross domain urls, however there might be a case where the dynamic url might be malicious and such security issue rises where the malicious code will execute in the same frame ,same domain of our website.
Is this assumption correct?
Is there any solution for this?
Any other suggestions?
Thanks,
Tal
we have a site with Iframes pointing to dynamic Urls (by user input). In case of a 404/500 or any other error, we want to replace the Iframe source with a different user friendly other URL.
So it sounds like you are making a sort of "browser in a web page."
For this we can use with the onerror event to identify when the dynamic websites have problems. (then, in case of problem replace the iframe url)
Yes, except not many things have onerror events. I assume you are aware of this from your comments on other answers. If I understand you right, you're talking about using a dummy script element to load the URL first (as a script, even though it's not really a script), and determine whether the URL is valid using the using onload/onerror handlers for the script element (onerror will not fire on a script error, only a network error).
This works also for cross domain urls, however there might be a case where the dynamic url might be malicious and such security issue rises where the malicious code will execute in the same frame ,same domain of our website.
Is this assumption correct?
Your assumption is correct. If the URL actually does contain a script, it will execute in the user's browser in the same domain as your site.
Is there any solution for this?
A simple workaround might be to do something like what jsfiddle.net does... have a separate subdomain act as a "firewall" between the third-party content and your real domain.
Any other suggestions?
The script preload hack is really just that, a hack. It misappropriates the script tag and makes needless requests. I would probably look into using XHR to fire off a HEAD request instead, or doing some light server-side proxying.
Yes, if you use a <script> tag to embed a remote JS file, you have a security problem as the code is going to be executed in the context of your page.
The only workaround idea that comes to mind is making a server-side request to the resource and parse the response headers. This however may behave differently from a client-side request, as the call will be coming from the server, so it'll have a different IP, different cookies, etc.
If the user can only specify the frame’s URL, then any scripting in the frame’s document would be run in the context of the frame’s document and not in the context of the parent document the frame is embedded.
The question whether a script running inside the frame can access the parent’s document (i. e. your document) depends on the origin of both documents: only if they are equal both document’s are said to be same origin. And only in that case one document can access the other document.