11

I'm getting this error :

Uncaught SecurityError: Blocked a frame with origin "https://lss-servicedesk.techteam.com" from accessing a frame with origin "http://mydomain.com".
The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "http". Protocols must match.

<FORM ACTION=https://lss-servicedesk.techteam.com/CAisd/pdmweb.exe METHOD=POST onsubmit="return checkform(this);">

Is there any way to get around this problem ? thanks in advance...

2 Answers2

6

You're getting 2 errors here. The first one is a cross-domain problem, and you won't be able to fix that. It is impossible for your site to access the loaded iframe's site at all. Otherwise, the browser would be really insecure, allowing one site to very easily get the user's settings on another site by just loading an iframe. So, you can't change anything within the iframe. The only thing you can do to the iframe's contents is iframeElement.src = '//otherurl.com'; - changing the source url of the iframe.

To fix the second problem, you can do the following: Instead of using http:// or https:// in the url you're defining in your scripts or forms, you can just use //. That will automatically 'fill in' the same protocol as the one you're using now. So, if you're on http:// at the moment, it'll load the iframe in http:// too, and vice versa.

Joeytje50
  • 18,636
  • 15
  • 63
  • 95
  • 4
    Notice that the use of protocol-relative URL:s require that the iframe-source page actually support both http and https requests. – Christofer Eliasson Feb 03 '14 at 11:06
  • 2
    Does `'://etc.etc'` actually work for a [protocol-relative URL](https://www.google.com/search?q=protocol+relative+url)? The ones I've seen have always been in the form `'//etc.etc'`. I think I'd recommend that just for the sake of consistency and familiarity even if both styles work. – Michael Geary Feb 03 '14 at 11:13
  • What's the rationale for an http site not being able to display an https iframe? It seems to be a safari only thing and it doesn't make any sense at all.. Preventing insecure content in a secure page makes sense; preventing secure content in an insecure page doesn't. – El Yobo Aug 26 '17 at 00:51
  • @ElYobo Perhaps it's a limitation of the software. Perhaps it can't initiate a secure connection when getting displayed from the insecure page, because there's some form of communication between the page and its child iframe. If the parent page can do anything at all with the child iframe, that's a security risk. That's a guess, but I think that might have something to do with why https within http is also disallowed. – Joeytje50 Aug 27 '17 at 20:16
0

I had the same issue with two different domains going to my webserver. Both of them had DNS settings set to redirect domain.com (without www) to http://www.domain.com. The one domain had issues similar to yours but it turned out that it was due to a DNS error where we had set FRAME to yes. After settings FRAME to no, it solved both issues (frame error and http/https error). It is a little thing but it caused the exact same error so just wanted to mention it as another possibility for anybody else who should stumble across this thread.

Corfitz.
  • 1,864
  • 3
  • 31
  • 53