Fix postmessage url origin check for IE

[bryanlandia]

The issue with IE11 never returning the url was caused by getURLOrigin not returning a match to the even origin URL, since IE automatically adds a port attribute of :443 to any https url, where other browsers don't add the port. Using host instead of hostname + port will be reliable across browsers, whether or not there is an explicit :portnum added to the tested url.

I used version 2.1.7 since I see (unreleased) 2.1.8 bumps the required XBlock version to 1.1. We are using 0.4.14 on staging and prod due to compatibility with the video xblock. edX Dogwood.3 uses 0.4, as well.

[bryanlandia]

(2) [ISC] Adjust theme to support IE11 container launching

[briandant]

Awesome, @bryanlandia!

It was our problem the whole time 🤦‍♂️

[briandant]

I used version 2.1.7 since I see (unreleased) 2.1.8 bumps the required XBlock version to 1.1. We are using 0.4.14 on staging and prod due to compatibility with the video xblock. edX Dogwood.3 uses 0.4, as well.

Good call. I plan to re-evaluate our XBlock requirements at some point. ALU need > 1.0, so they have 2.1.8, IIRC, but I don't how our code will play with the various versions of XBlock.py.

[bryanlandia]

Hey @briandant Thinking about versions a little bit more here. I think 2.1.8 needs to be 2.2.0. It's essentially backward incompatible since the XBlock dependency is not safe for Dogwood, where it is still deployed in production. I'd like to make my change 2.1.8 but the next patch version is taken. Is the unreleased 2.1.8 in use anywhere?

[briandant]

@bryanlandia: Yes, it is released to the ALU cluster.

Would it be a problem to use 2.1.9 for your changes, and then I'll move the XBlock dependency changes into 2.2.x in the future? (When I do this, I'll kill the 2.1.8 changes and probably just skip this tag.

Thanks for your persistence on this!

[bryanlandia]

@briandant OK, sure, I will fix up the version history and use 2.1.9 then.

[bryanlandia]

@briandant Looks like you incorporated the full changes into 2.1.10 so just for posterity's sake I tagged v2.1.9 at the commit cf452f9

https://github.com/appsembler/xblock-launchcontainer/releases/tag/v2.1.9

[bryanlandia]

@briandant I had gotten confused. Actually, at least out of the box, Ficus still uses XBlock 0.4.13 as well. It's Ginkgo that jumps to XBlock 1.0.0. So, 2.2.0 will break anything pre-Ginkgo, not just Dogwood.

[briandant]

Ah, right. I’m remembering that I bumped these dependancies because ALU was on Ginko. Only they have received the `2.1.8.prerelease.3`, so we can assume that all other servers are happy with the versioning of XBlock we have in `setup.py`. Thanks for continuing to watch this and push us (me) toward good versioning and deployment practices.

…

On 15 May 2018, at 22:51, Bryan Wilson wrote: @briandant I had gotten confused. Actually, at least out of the box, Ficus still uses XBlock 0.4.13 as well. It's Ginkgo that jumps to XBlock 1.0.0. So, 2.2.0 will break anything pre-Ginkgo, not just Dogwood. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #22 (comment)