Closed Bug 852796 Opened 12 years ago Closed 11 years ago

postMessage is sensitive to IDN vs punycode in the origin argument

Categories

(Core :: DOM: Core & HTML, defect)

21 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 720331

People

(Reporter: BYK, Unassigned)

Details

This is kind of a hard to explain problem so here it goes:

When you create an iframe inside a domain that has unicode characters in it, the iframe's document.referrer property has the decoded version of the url where as document.location.href on the parent page hold the encoded, unicode version which creates an origin mismatch when trying to use postMessage and using origin guessing via the iframe's document.referrer property.

A sample page is here: http://ит-7.рф/test.html

The Disqus embed checks document.referrer and the origin of the message received from postMessage and the check fails. This works properly in Chrome since they use decoded URLs everywhere.
looks like a dupe of bug 720331

btw: Firefox:general for content bugs is in general wrong, Please either use Firefox:untriaged or choose the right Product/component.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
As filed, this is not a duplicate.  postMessage should not depend on what's going on with IDN: origin compares are supposed to always be done in punycode.
Status: RESOLVED → REOPENED
Component: General → DOM
Product: Firefox → Core
Resolution: DUPLICATE → ---
Summary: document.referrer is decoded when the host page url has unicode chars in it → postMessage is sensitive to IDN vs punycode in the origin argument
So I just checked, and we do in fact make sure that the two things we're comparing are not different in terms of punycode vs Unicode.

In particular, on the test page listed in comment 0 I never see us take the "don't fire the message event because the origins don't match" codepath.  So whatever is going on there doesn't seem to have anything to do with the document.referrer origin bit...

And actually, I just tried commenting out the same-origin check entirely and the example page still looks broken to me.
Flags: needinfo?(madbyk)
It is a duplicate of bug 720331 indeed. May be the postMessage stuff and my wording confused you. Sorry for being late with the response.
Status: REOPENED → RESOLVED
Closed: 12 years ago11 years ago
Flags: needinfo?(madbyk)
Resolution: --- → DUPLICATE
OK, so the sample page in comment 0 has nothing to do with this bug as reported?

Still trying to understand what this bug is actually about, since as far as I can tell bug 720331 is either invalid or wontfix....
Flags: needinfo?(madbyk)
It has =) Disqus used to extract the "origin" from the iframe's referrer property and then check that against the origin that was passed with the message coming from the postMessage call.

The origin in the postMessage event data was in unicode and the referrer was in punycode so they did not match, resulting in a false negative(mistaken as coming from a different origin).
Flags: needinfo?(madbyk)
Oh, I see.  A broken origin check on _their_ end, ok.  ;)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.