Alan K [:ack] Reporter
	Description • 11 years ago

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?

	John Karahalis [:openjck]
	Comment 1 • 11 years ago

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

	Alan K [:ack] Reporter
	Comment 2 • 11 years ago

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?

	John Karahalis [:openjck]
	Comment 3 • 11 years ago

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

	Les Orchard [:lorchard]
	Comment 4 • 11 years ago

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?

	Les Orchard [:lorchard]
	Comment 5 • 11 years ago

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

	John Karahalis [:openjck]
	Comment 6 • 11 years ago

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

	Alan K [:ack] Reporter
	Comment 7 • 11 years ago

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.

	David Walsh :davidwalsh
	Comment 8 • 11 years ago

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?

	Alan K [:ack] Reporter
	Comment 9 • 11 years ago

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?

	David Walsh :davidwalsh
	Comment 10 • 11 years ago

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...

	Alan K [:ack] Reporter
	Comment 11 • 11 years ago

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?

	David Walsh :davidwalsh
	Comment 12 • 11 years ago

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?

	Alan K [:ack] Reporter
	Comment 13 • 11 years ago

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

	Chris Turra [:cturra]
	Comment 14 • 11 years ago

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>

	David Walsh :davidwalsh
	Comment 15 • 11 years ago

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?

	Martin Best (:mbest)
	Comment 16 • 11 years ago

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?

	Alan K [:ack] Reporter
	Comment 17 • 11 years ago

@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.

	Martin Best (:mbest)
	Comment 18 • 11 years ago

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.

	Chris Turra [:cturra]
	Comment 19 • 11 years ago

(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>

	Chris Turra [:cturra]
	Comment 20 • 11 years ago

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

	Martin Best (:mbest)
	Comment 21 • 11 years ago

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

	Alan K [:ack] Reporter
	Comment 22 • 11 years ago

Fixed now.

	Martin Best (:mbest)
	Comment 23 • 11 years ago

Awesome, thanks for jumping on this.

	Marco Mucci [:MarcoM]
	Comment 24 • 11 years ago

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