We are getting this error
on the click of submit on the hosted payment form.
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://xxxx.xxx.com') does not match the recipient window's origin ('null').
I read some documentation in internet and noted the problem there mentioned as well . Adding for reference
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/fsDaKFqvU20
The hosted payment iframe failing Chrome60 , but is working in other browsers (namely Firefox/IE)
Please advise ,
Solved! Go to Solution.
โ08-09-2017 09:07 AM
Thanks @debasishbose2k, @NexusSoftware, and everyone else on this thread for sharing your experiences. We've got a good understanding of the challenges now. From a documentation perspective, we'll try to come up with ways to help people understand the ins and outs of frame security and give some recommendations. We also have engineers looking at what possible solutions we can implement on our end.
Again, thanks!
โ08-16-2017 11:26 AM
Hi,
Thanks for posting the solution.
I have a question related to this. Since X-Frames is deprecated, does CSP server the same purpose from other servers to not allow framing.
โ08-21-2017 09:24 AM
Hi @vallapus,
It's my understanding that it does, but it may not be as simple as just replacing one header with another, depending on which browsers you're trying to support. You may have to determine whether your targeted browsers all support the aspects of CSP that you want, and if not, come up with some hybrid approach.
โ08-22-2017 04:51 PM
We are also facing same issue.
Could you please update the implementation document with some proper hybrid approach.
Also it would be helpful if authorize.net publish this on news and update page.
I will try with the solution suggested by @NexusSoftware and come up with result.
โ09-13-2017 02:35 AM
Hi @raviparmarce88,
Thanks for the input.
This isn't really a problem specific to us, but to anyone using any CSP headers or X-Frame-Options on their sites. If you don't use those headers, there's no problems with our forms, and if you do, you will run into different behavior on newer browsers when you start getting into frames within frames like this, whether we're involved or not.
If someone runs into that problem with our services, we still want to help them as much as we can, though. I'll make sure we at least address this in our developer FAQ, although a blog post would be a good idea. I'd like to encourage more people to think about security anyway, so a blog post walking someone through the "right" way to lock down our frames would definitely be useful.
โ09-13-2017 09:23 AM
i m also getting same error on Chrome browzer..
Refused to display 'https://mysiteurl.com/scripts/IFrameCommunicator.html#action=resizeWindow&width=736&height=401' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
15:20:54.600
Any Sloution on this...
โ04-27-2018 03:00 AM
Any ideas on this? I've read through all the posts on the iframe on the forum and not having much luck getting the communicator to work because of the 'sameorigin' issue
โ07-12-2018 01:45 PM
am also getting this issue recently in my chrome Version 67.0.3396.99 (Official Build) (64-bit).
Failed to execute 'postMessage' on 'DOMWindow': The target origin provided (server URL on https) does not match the recipient window's origin ('https://test.authorize.net').
same for production.
โ04-19-2019 06:23 AM - edited โ04-19-2019 06:25 AM
Hey fellow Developers,
I too face the similar issue.
I am using hosted form in Laravel framework.
Now tricky part is that I am only getting this issue when iframecommuicator return url is under Laravel auth. Post removing from auth, it is working fine and no domwindow or corss origin error.
I have tried adding "allowing cross origin requests in Laravel routes too" with no success.
If any one can suggest configuration or setting here specifically to get rid of this issue.
P.S. This issue only happens in chrome and not in firefox.
โ09-08-2020 04:53 AM
We are having the same issue and applying the content-security-policy via web.config file (asp.net/IIS) is not working. We are passing a paymentProfileId in the token.
Example of web.config:
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="frame-ancestors 'self' https://localhost:44300 *.ourdomain.com *.authorize.net" />
</customHeaders>
</httpProtocol>
We have even tried with the Content-Security-Policy-Report-Only but still no luck, it acts the same.
What can we do when the content-security-policy is not working?
โ12-31-2020 08:59 AM