I'm getting this warning in Chrome when I try to show a dialog (alert()/confirm()/prompt()) from an iframe. Both domains belong to me.
A different origin subframe tried to create a JavaScript dialog. This is no longer allowed and was blocked. See https://www.chromestatus.com/feature/5148698084376576 for more details.
Could I resolve this via .htaccess or with an HTTP header or anything like that?
Use top.alert(), top.confirm(), & top.prompt() instead, which, if you have your CORS set up, will use the parent window's (if there is one) dialogs which are not blocked by this Chrome update.
I have a problem when calling a URL with jquery. It works fine in IE but in Chrome and Firefox, I get an error message.
I'm opening the HTML file from my computer, and I need either Firefox or Chrome to work for a testing purpose.
I've tried opening Chrome with a commandline, I've downloaded an Addon to prevent a CORS error I was getting.
I've also tried turning the "get" methods into getJSON, I didn't get CORB errors anymore, but the code in the .done functions didn't work on Chrome and Firefox (it did work on IE though). I've put "&callback=?" at the end of the URLs (while still using getJSON function) but nothing changed.
Here's the code:
$.get(URL1)
.done(function(data){
$(data["projects"]).each(function(l){
arrProjDev[l]=data["projects"][l];
})
$.get(URL2)
.done(function(response){
$(response["result"]).each(function(m){
arrTaskDev[m]= response["result"][m];
})
$.get(URL3)
.done(function(responseTr){
$(responseTr["result"]).each(function(n){
arrTriggDev[n]=responseTr["result"][n];
})
Each URL returns a JSON object.
A tree view is supposed to appear in a specific div, and heach row is an object contained in the JSON files.
But when I try to open the app in Chrome, I get this error message:
jquery.min.js:4 Cross-Origin Read Blocking (CORB) blocked cross-origin response http://URL with MIME type application/json. See https://www.chromestatus.com/feature/5629709824032768 for more details.
In firefox, it's more complicated, the error message is in french but it says that a Cross-Origin Request was blocked and that "same origin" politics doesnt allow me the browser to open the URL because the CORS header "Access-Control-Allow-Origin " is missing.
It looks a lot like the problem I've already solved in Chrome with the addon but I can't solve it on firefox.
I have latest version of ckeditor. I did file upload to my remote service. that service after uploading, returns uploaded file link. that is included as iframe 'upload' tab.
So that is all ok. But when I try to switch tab or close image uploader popup window 'ckeditor' throws error:
"Blocked a frame with origin "http://localhost:3101" from accessing a frame with origin "http://localhost:61666". Protocols, domains, and ports must match."
Is where any way to fix this problem?
That is a security standard. Browser auto check and prevent it like default way. Have no method to pass it.
But in your case I have a trick to resolve this problem, you can try this:
After click "send it to server" and receive a response.
Detect your iframe source by id in DOM
Change the iframe's source domain to current domain. (important thing of this trick to pass error "Blocked a frame with origin..." )
And do continue like as you did.
I'm trying to get an image from the link:
http://www.ims.gov.il/Ims/Map/MapRender.aspx?type=weather&LangId=1&Optional=c&Tab=Temperature
Sometimes it works, and at other times instead of getting an image I receive this strange HTML:
<html><body><script>document.cookie='rrrrrrr=27b8c912rrrrrrr_27b8c912; path=/';window.location.href=window.location.href;</script></body></html>
What does it mean and how can I bypass this to get the image?
I've encountered this problem in my Android app which uses URLConnection, and reproduced it in chrome with incognito mode and blocked javascript and cookies.
The response is setting a cookie and then attempting to reload the page. Some things you could try:
Just re-request the image if the first attempt fails.
Try setting the cookie yourself in the URL request.
For posting AJAX forms in a form with many parameters, I am using a solution of creating an iframe, posting the form to it by POST, and then accessing the iframe's content.
specifically, I am accessing the content like this:
$("some_iframe_id").get(0).contentWindow.document
I tested it and it worked.
On some of the pages, I started getting an "Access is denied" error. As far as I know, this shouldn't happen if the iframe is served from the same domain.
I'm pretty sure it was working before. Anybody have a clue?
If I'm not being clear enough: I'm posting to the same domain. So this is not a cross-domain request. I am testing on IE only.
P.S. I can't use simple ajax POST queries (don't ask...)
Solved it by myself!
The problem was, that even though the correct response was being sent (verified with Fiddler), it was being sent with an HTTP 500 error code (instead of 200).
So it turns out, that if a response is sent with an error code, IE replaces the content of the iframe with an error message loaded from the disk (res://ieframe.dll/http_500.htm), and that causes the cross-domain access denied error.
Beware of security limitations associated to iFrames, like Cross domain restriction (aka CORS). Below are 3 common errors related to CORS :
Load an iFrame with a different domain. (Ex: opening "www.foo.com" while top frame is "www.ooof.com")
Load an iFrame with a different port: iFrame's URL port differs from the one of the top frame.
Different protocols : loading iFrame resource via HTTPS while parent Frame uses HTTP.
My issue was the X-Frame-Options HTTP header. My Apache configuration has it set to:
Header always append X-Frame-Options DENY
Removing it allowed it to work. Specifically in my case I was using iframe transport for jQuery with the jQuery file upload plugin to upload files in IE 9 and IE 10.
I know this question is super-old, but I wanted to mention that the above answer worked for me: setting the document.domain to be the same on each of the pages-- the parent page and the iframe page. However in my search, I did find this interesting article:
http://softwareas.com/cross-domain-communication-with-iframes
Note if you have a iframe with src='javascript:void(0)' then javascript like frame.document.location =... will fail with Access Denied error in IE. Was using a javascript library that interacts with a target frame. Even though the location it was trying to change the frame to was on the same domain as parent, the iframe was initially set to javascript:void which triggered the cross domain access denied error.
To solve this I created a blank.html page in my site and if I need to declare an iframe in advance that will initially be blank until changed via javascript, then I point it to the blank page so that src='/content/blank.html' is in the same domain.
Alternatively you could create the iframe completely through javascript so that you can set the src when it is created, but in my case I was using a library which reqired an iframe already be declared on the page.
Basically, this error occurs when the document in frame and outside of ii have different domains. So to prevent cross-side scripting browsers disable such execution.
if it is a domain issue (or subdomain) such as www.foo.com sending a request to www.api.foo.com
on each page you can set the
document.domain = www.foo.com
to allow for "cross-domain" permissions