connectToChild.childOrigin

[cda963]

I need to specify the child's origin, when the parent and the child are on the same domain, but different sub-domains.

I'm getting the following error: Parent received handshake from origin https://child.domain.com which did not match expected origin https://parent.domain.com

[Aaronius]

What is the value of the src attribute on the iframe?

[cda963]

The iframe's src is something like https://child.domain.com. Both the parent and the child are on the same domain, just different sub-domains.

[Aaronius]

Can you put a breakpoint on this line: https://github.com/Aaronius/penpal/blob/918c67a608bf827383101d6fe22d827b128f04e8/src/getOriginFromSrc.js#L16 and step through the code? Somehow, in your case, getOriginFromSrc seems to be returning https://parent.domain.com instead of https://child.domain.com.

[cda963]

I will give it a try in the next dev sprint, but at the moment we had to find another quick solution, so we went with the vanilla "postMessage". Thanks.

[radarfox]

I was about to suggest the same feature, even with the same name, so this looks like a good idea.

I'm developing the web app for the smart TV platforms (Samsung and LG) and I ran into this issue. The problem is, that these platforms run on file:// protocol, but with a non-null origins in the messages. Here is the table that shows the problem:

Browser	Origin of location	Origin of postMessage
Chrome 74	file://	null
LG webOS	file://com.lg.app.signage	file://com.lg.app.signage
Samsung Tizen	file://	file://

The file:// paths on these platforms are quite complicated and there is no way to deduce the origin from them.

So the solution i came with is adding a optional option called childOrigin to the connectToChild function. If it is explicitly defined, the getOriginFromSrc(iframe.src) is not called and it is replaced by the childOrigin option.

I also disabled the iframe.src check, as it's value is no longer used and needed.

PS: Thank you much for this great library, saved me a couple of hours!

[Aaronius]

Oh that's interesting...and annoying that they aren't consistent. Thanks for the detail @radarfox. I need to take a while to digest this. @cojocaru-dragos-alexandru, are you dealing with the file:// protocol as well?

[cda963]

Hi guys, the protocol I was using was https. I basically had 2 websites: a "parent" one and another one displayed inside a parent's iframe.

[radarfox]

I have done some further research and found out, that if you run Chrome with --allow-file-access-from-files CLI argument, then the origin in the messages also changes to file://. Here is the updated table:

Browser	Origin of location	Origin of postMessage
Chrome 75	file://	null
Chrome 75 with --allow-file-access-from-files	file://	file://
LG webOS	file://com.lg.app.signage	file://com.lg.app.signage
Samsung Tizen	file://	file://

So that is another proof, that parsing the origin from URL won't work for 100% of the cases. It would be nice, if the library would offer an alternative way to handle those cases.

Let me know if you need any help from me with implementing this.

[Aaronius]

Could you run npm install penpal@next and make sure it solves your issues? You should be able to pass childOrigin as an option into connectToChild now.

[Aaronius]

BTW, the updated readme can be found at https://github.com/Aaronius/penpal/tree/v4.1.0. Feel free to give that a read and make sure it makes sense.

[radarfox]

Works as expected, thank you very much! I'm looking forward to the official release.

Readme seems understandable. Maybe you can mention that iframe.src is not requred in this case and you can add it later after calling connectToChild.

[Aaronius]

Released in v4.1.1.