- recaptcha
- HTML
- JavaScript
- PHP
What is causing the following CORS error.
Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘http://themagnolia.com’) does not match the recipient window’s origin (‘https://www.themagnolia.com’). spam-block.htm
This client recently upgraded to FTP-SSL protocol. I have reviewed the files involved and I don't see where http://themagnolia.com is referenced.
Does anyone know how to isolate this error? I've attached the files that seem to be involved.
reCaptcha-test-3.htm
reCaptcha-test-3.php
spam-block.htm
sendForm.php
This client recently upgraded to FTP-SSL protocol. I have reviewed the files involved and I don't see where http://themagnolia.com is referenced.
Does anyone know how to isolate this error? I've attached the files that seem to be involved.
reCaptcha-test-3.htm
reCaptcha-test-3.php
spam-block.htm
sendForm.php
CORS is triggered when ONE of the following does not match
Protocol (http vs https)
URL
Port
In your case the protocol is different - you are making an HTTPS call from a page loaded with HTTP - that will trigger a CORS warning.
Change your call to either HTTPS or an agnostic url (leave the protocol off)
Example
Instead of
Protocol (http vs https)
URL
Port
In your case the protocol is different - you are making an HTTPS call from a page loaded with HTTP - that will trigger a CORS warning.
Change your call to either HTTPS or an agnostic url (leave the protocol off)
Example
Instead of
$.post("https://www.themagnolia.com/reCaptcha-test-3.php"
$.post("//www.themagnolia.com/reCaptcha-test-3.php"
Julian... I will follow your advice and go the agnostic route. I id edit all the page & script code and made sure there were only https references. Thank you for a helpful comment. One thing I don't understand is how a http vs https mismatch comes into being if all the code is created in the same environment and no conflicts are hardcoded.
The reason is that you can route a page based on protocol so there is no guarantee it is going to the same place as the http version. For this reason it is assumed that an https request from an http page (or vice versa) is going to a different page.
I'm not sure I'm following your explanation completely.
The reason is that you can route a page based on protocol so there is no guarantee it is going to the same place as the http version.
All the pages involved are created inside an https domain (https://www.themagnolia.com). I can't find any explicit references to a http domain in the code. I have modified the web.config file to force https protocol. So I'm thinking all routings are https to https in the same URL.
For this reason it is assumed that an https request from an http page (or vice versa) is going to a different page.
Similar to the above comment, I don't see why an http page is involved at all.
I will switch everything to the agnostic approach as you suggest. Seems like a smart coding practice, but I'm just trying to understand what is really going on in the background.
Thanks for your help.
The reason is that you can route a page based on protocol so there is no guarantee it is going to the same place as the http version.
All the pages involved are created inside an https domain (https://www.themagnolia.com). I can't find any explicit references to a http domain in the code. I have modified the web.config file to force https protocol. So I'm thinking all routings are https to https in the same URL.
For this reason it is assumed that an https request from an http page (or vice versa) is going to a different page.
Similar to the above comment, I don't see why an http page is involved at all.
I will switch everything to the agnostic approach as you suggest. Seems like a smart coding practice, but I'm just trying to understand what is really going on in the background.
Thanks for your help.
What I was referring to was the rationale behind the decision to treat HTTP requests to the same domain as being separate from HTTPS requests to that domain. Because it is possible that the http address of a domain goes to a different place than the https - there is no guarantee that an http request from a page loaded over https is in fact going to the same place - from the browsers perspective.
The browser must therefore be conservative and assume ANY request on a different protocol to the same domain is completely different location and therefore CORS comes into play.
The browser must therefore be conservative and assume ANY request on a different protocol to the same domain is completely different location and therefore CORS comes into play.
Similar to the above comment, I don't see why an http page is involved at all.You loaded the page using HTTPS and made an AJAX call with HTTP - you broke the rules the browser is forced to follow and hence triggered a CORS error.
OK! Now I get it. It Looks like I can just change the AJAX request to https? or is it better to use the agnostic approach? I was under the mistaken impression that AJAX required http even if going https?
OK! Now I get it. It Looks like I can just change the AJAX request to https? or is it better to use the agnostic approach? I was under the mistaken impression that AJAX required http even if going https?AJAX is just an XHR request - you tell it how to make that request. Agnostic is better - that is why I recommended it.
