(In reply to Beatriz Rizental [:brizental] from comment #16) > Okay, I have some good news here. > > I researched more about this, and I stumbled on [this article](https://developer.chrome.com/extensions/xhr) which mentions that when a web extension needs to do a cross-origin request it must add the origin to its permissions list and that will bypass CORS. I tested and indeed it works: https://debug-ping-preview.firebaseapp.com/pings/gleanjs-no-cors-test (ping sent from a web extension by adding `"https://incoming.telemetry.mozilla.org/"` to the permissions list on the `manifest.json`). See also [Host permissions](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions). > > This is good because it loosens our timeline here. We plan to instrument Ion/Rally and Bergamot with Glean.js by late January/2021, but both are web extensions. We still need to figure out a way to send Glean.js pings from websites to incoming.tmo, which will require that server to support CORS, but we don't have urgency for that. Thanks for looking into this. Looks like Pioneer/Ion/Rally won't need CORS then. Let me clear the ni? for Wesley (thanks Wesley!). > Maybe, instead of `Access-Control-Allow-Headers: *` we could list specifically the websites we instrument with Glean.js here, so e.g. `Access-Control-Allow-Headers: https://mozilla.com https://mozilla.org ...`, this would require some sort of registration process for everytime a Mozilla website starts using Glean.js, but there is already the application-id registration anyways, so maybe it is not a big deal? This pretty much depends on how much time it takes to update this, who needs to update this every time a product needs to support Glean.js. Right now, it takes less than a day for an app id to be enabled (it actually takes a few minutes). I would like us to not deviate from this kind of SLA. Moreover, by requiring enabling on the ops side, it would make it not possible to use the glean debug view without using a CORS proxy, which is very bad.
Bug 1676676 Comment 17 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Beatriz Rizental [:brizental] from comment #16) > Okay, I have some good news here. > > I researched more about this, and I stumbled on [this article](https://developer.chrome.com/extensions/xhr) which mentions that when a web extension needs to do a cross-origin request it must add the origin to its permissions list and that will bypass CORS. I tested and indeed it works: https://debug-ping-preview.firebaseapp.com/pings/gleanjs-no-cors-test (ping sent from a web extension by adding `"https://incoming.telemetry.mozilla.org/"` to the permissions list on the `manifest.json`). See also [Host permissions](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions). > > This is good because it loosens our timeline here. We plan to instrument Ion/Rally and Bergamot with Glean.js by late January/2021, but both are web extensions. We still need to figure out a way to send Glean.js pings from websites to incoming.tmo, which will require that server to support CORS, but we don't have urgency for that. Thanks for looking into this. Looks like Pioneer/Ion/Rally won't need CORS then. Let me clear the ni? for Wesley (thanks Wesley!). > Maybe, instead of `Access-Control-Allow-Headers: *` we could list specifically the websites we instrument with Glean.js here, so e.g. `Access-Control-Allow-Headers: https://mozilla.com https://mozilla.org ...`, this would require some sort of registration process for everytime a Mozilla website starts using Glean.js, but there is already the application-id registration anyways, so maybe it is not a big deal? This pretty much depends on how much time it takes to update this, who needs to update this every time a product needs to support Glean.js. Right now, it takes less than a day for an app id to be enabled (it actually takes a few minutes). I would like us to not deviate from this kind of SLA. Moreover, by requiring enabling on the ops side, it would make it not possible to use the glean debug view without using a CORS proxy, which is very bad for the developer ergonomics.