What did you do? ================ Try and start a new multiplayer game (https://developer.cdn.mozilla.net/media/uploads/demos/a/z/azakai/3baf4ad7e600cbda06ec46efec5ec3b8/bananabread_1371837811_demo_package/list.html) What happened? ============== [12:44:04.168] "Error in connect(): [Exception... "The operation is insecure." code: "18" nsresult: "0x80530012 (SecurityError)" location: " https://developer.cdn.mozilla.net/media/uploads/demos/a/z/azakai/3baf4ad7e600cbda06ec46efec5ec3b8/bananabread_1371837811_demo_package/bb.jsLine: 3468"]" What should have happened? ========================== It used to load and run without issue. Looks like this might be caused by accessing an insecure site from a secure one, but the websockets connection is going to a secure site. Is there anything else we should know? ====================================== This needs to start working again. Can we put this on http (non-SSL) instead?

Is this something that can be fixed on the demo side? Or do we know that Demo Studio platform changes are needed?

I'm not sure if this is an issue with the demo. It was working as of 20 June using firefox Nightly. I'm currently not able to use it even with Aurora. Did something change on the demo site that might have broken secure cross-site websockets?

Not that I know of. Maybe someone on the dev team knows?

I don't think we've deployed anything with respect to demo studio beyond some dev derby copy updates. I'm under the impression, though, that cross-site websocket access is controlled by the remote site with the websockets server - and that's not MDN / Demo Studio as far as I know. I'm not at all familiar with what bananabread is doing, or where the multiplayer server is, but are all the CORS headers copacetic & etc?

Hmm, and I can't reproduce this error. I just loaded up the demo, started a multiplayer game, and it seems to be working.

Same here. I think this is only happening in Aurora or newer.

This is definitely broken in FF 22: [14:22:31.219] Error in connect(): [Exception... "The operation is insecure." code: "18" nsresult: "0x80530012 (SecurityError)" location: "https://developer.cdn.mozilla.net/media/uploads/demos/a/z/azakai/3baf4ad7e600cbda06ec46efec5ec3b8/bananabread_1371837811_demo_package/bb.js Line: 3468"] Starting a multiplayer game is not a sufficient test. Even though the game starts, no one can join it because of the error above.

Doing a quick look at the page JS source, I'm seeing "https://mdsw.ch:8080" references as a "broker". Supposedly it's identifying itself as "modeswitch.org", which Firefox warns me about. Can someone who created this demo shed light on this?

Yeah, the webrtc broker is hosted on one of my machines. I'm not seeing any warnings though. Can you please paste the text or send me a screencap?

Bleh, unfortunately I can't trigger said warning again, even when I clear cache. You can see what we've pushed since your last-worked date: https://github.com/mozilla/kuma/pulls?direction=desc&page=1&sort=created&state=closed I don't think we could have done anything to cause this issue. Is there any networking being routed through MDN's kuma repo itself? Can a BB dev check to see what attempted connection is failing? I'm not sure there's much we can do here...

It's the secure websockets connection to the webrtc broker service that's failing. I have this running on another SSL-enabled server. Examining the headers, I notice that 'Access-Control-Allow-Origin: *' is present on my server but missing in the headers returned by the demo site. If you updated your web server, or changed the settings recently that would account for the breakage. I'm fairly certain that this is the problem. Is this something you're able to fix?

We recently updated the .htaccess on developer.cdn.mozilla.net to allow for cross-domain fonts; maybe that caused the header issue? https://bugzilla.mozilla.org/show_bug.cgi?id=881315 CC'ing cturra as he made the update on the CDN and may need to help us out. In the mean time, akligman, do you know which types of connections/file extensions need that ACAO heading?

Probably just the HTML and JS files (.html and .js). I'm only making x-origin requests for secure websockets.

we are only setting the 'Access-Control-Allow-Origin' header for fonts. more details on this setup in bug 881315. <FilesMatch "\.(eot|ttf|otf|woff)"> Header set Access-Control-Allow-Origin "*" </FilesMatch>

I'm having a really hard time figuring out what the issue is. I actually didn't see the original error today. I also tried creating a game, then going to another browser to join the game, and didn't see the original game in the list. Any more clues or direction you can give akligman?

Has this been fixed? Looks like to problem has been around since WebRTC was released and quite a while now. What can we do to resolve this as this one of the more prominent demos of WebRTC data-channels?

@cturra: The demo was working as of a few weeks ago and then suddenly stopped working, even in browsers where it had previously worked. I'm pretty sure we need ACAO enabled for script and html files. @davidwalsh: The reason you don't see the game you created is because your browser can't get a WSS connection to the list service. The browser complains about a security error, I think because ACAO isn't enabled for script files. @mbest: This hasn't been fixed yet. I'm moving the webrtc broker onto a mozilla box (it's currently hosted on a personal machine), and if we can't get the issue resolved on the demo site I'll host the content there as well.

Thanks for the info, please make this a high priority as this is a very public demo and it looks really bad to have this broken at the moment WebRTC is released.

(In reply to akligman from comment #17) > @cturra: The demo was working as of a few weeks ago and then suddenly > stopped working, even in browsers where it had previously worked. I'm pretty > sure we need ACAO enabled for script and html files. i have just committed the following to puppet. it should be available shortly once the change has been pushed by our puppet masters and the CDNs clear their cache. - # bug 881315 - <FilesMatch "\.(eot|ttf|otf|woff)"> + # bug 881315 & 886889#c16 + <FilesMatch "\.(eot|ttf|otf|woff|js|html)"> Header set Access-Control-Allow-Origin "*" </FilesMatch>

complete. $ curl -I https://developer.cdn.mozilla.net/media/uploads/demos/a/z/azakai/3baf4ad7e600cbda06ec46efec5ec3b8/bananabread_1371837811_demo_package/bb.js HTTP/1.1 200 OK Server: Apache X-Backend-Server: developer3.webapp.scl3.mozilla.com Content-Type: text/javascript Access-Control-Allow-Origin: * ETag: "4dfade197ecd5" Last-Modified: Fri, 21 Jun 2013 18:03:34 GMT X-Cache-Info: caching Cache-Control: max-age=43200 Expires: Thu, 11 Jul 2013 04:54:10 GMT Date: Wed, 10 Jul 2013 16:54:10 GMT Connection: keep-alive

I'm on the road, can someone confirm that the fix has worked?

Fixed now.

Awesome, thanks for jumping on this.

Does anyone know which version of Firefox this fix was released on?