790806 - Enable Bedrock Servers To Serve Tabzilla

Status: VERIFIED FIXED

(Infrastructure & Operations Graveyard :: WebOps: Other, task, P4)

Description

[Ben (:bensternthal)]

We will be moving tabzilla into bedrock. As part of this project (see bug 776905) the tabzilla files will be served from the bedrock servers.

This will/may include
- css
- js
- images
- font files

Tabzilla is used on a variety of websites and we want to make sure Access-Control-Allow-Origin is set correctly and does not block any of these assets.

Can you advise on what our approach here should be.

Comment 1

[Jake Maul [:jakem]]

All we need to know to make the headers get set right is:

1) What files/paths need the header set a certain way, and
2) What the header should be set to in those cases.

I presume you're just checking this into the main bedrock /media/ dir somewhere?

Comment 2

[Ricky Rosario [:rrosario, :r1cky]]

If the Access-Control-Allow-Origin is setup properly for the fonts, SUMO can start using the fonts for our redesign which is starting to rollout. So it would be awesome if that part could be done ASAP :).

Comment 3

[Ben (:bensternthal)]

Jake looks like Ricky and the SUMO team have an immediate need for the font outside of moving tabzilla into bedrock.

So for now can we...

allow *.mozilla.org for this path /media/fonts

example: https://github.com/mozilla/bedrock/tree/master/media/fonts

I personally do not see any issues allowing this whole directory (especially for *.mozilla.org) but if that is a concern for someone let me know.


The correct fonts are already there and live.

Let me know if you need any additional information.

Comment 4

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Ben (:bensternthal) from comment #3)
> allow *.mozilla.org for this path /media/fonts

*.allizom.org would be required for our staging and dev sites. I guess for local development we will be out of luck?

Comment 5

[Shyam Mani [:fox2mike]]

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #4)

> *.allizom.org would be required for our staging and dev sites. I guess for
> local development we will be out of luck?

I guess webops could allow the VPNs, if you're on the VPN, you'll be in luck. The other case is just too wide open/too many options to allow.

Comment 6

[Anthony Ricaud (:rik)]

Can we just use a full wildcard?

Comment 7

[Ben (:bensternthal)]

Any objections to full wildcard?

The only issue could possibly see is hotlinking and I do not see this as an issue for the fonts.

For the css,js etc to support tabzilla we might want to be more restrictive. But for now if we can move forward with wildcard allowing the font directory... SUMO can start to use these.

Comment 8

[Jake Maul [:jakem]]

From the Ops side: it's not especially relevant to us... same setting(s) either way, just changes what they're set *to*.

The concern seems to be 2-fold:

1) Are we concerned that non-Mozilla stuff might theme themselves using Tabzilla materials? That is, could nefarious 3rd parties use a full wildcard to make themselves look more like a Mozilla site, and thus appear more official (even including www.mozilla.org content)?

2) Are we concerned about hotlinking bandwidth? I posit that this is probably not significant. The only people who'd want to use this stuff are people looking to, legitimately or illegitimately, make a site that looks like a Mozilla site. In the former case we're probably happy for them to link to us directly... in the latter, a CORS header isn't going to prevent them from saving the file locally and making the evil site anyway... having them hit us at least gives us a chance to see that such a site exists. :)

However, my input should in no way be considered authoritative into the benefits or drawbacks to various CORS header settings. IANACORSE. :)

Comment 9

[Anthony Ricaud (:rik)]

CORS is actually not used for CSS, JS or images. CORS is only required for fonts and JSON (basically).

So we only need /media/fonts to be CORS-ready.

I say we go with the universal wildcard. CORS actually does not support semi-wildcard like *.allizom.org. To restrict to our domains, we would need to read the Origin request header, check it against a list and set Access-Control-Allow-Origin to the Origin header if it's a valid origin. Too much work and maintenance for this purpose.

If we see a case where we should restrict our fonts usage, we'll reconsider.

Comment 10

[Ben (:bensternthal)]

Ok lets move forward with the wildcard for /media/fonts.

Jake do you need anything else... if not... go forth!

Comment 11

[Jake Maul [:jakem]]

How about we check in a .htaccess file into https://github.com/mozilla/bedrock/tree/master/media/fonts ?

It would be one line, like this:

Header set Access-Control-Allow-Origin "*"

This would make it webdev-managed, and would not need IT/WebOps assistance to update it. I'm hoping we can do the same thing over in bug 742890 for cache headers. SUMO does this currently, and it seems to work well for them.


To get a little more specific and flexible, you could also do something like this in /media/.htaccess (one leve higher):

<FilesMatch "\.(ttf|woff|eot)$">
    Header set Access-Control-Allow-Origin "*"
</FilesMatch>

It's more complicated, but it frees you from worrying about the exact path and helps to centralize .htaccess rules in one place.


Either solution has the benefit of making you slightly more autonomous and not blocked by IT. :)

Comment 12

[Ben (:bensternthal)]

Pull request with this is now here:

https://github.com/mozilla/bedrock/pull/367

Comment 13

[[github robot]]

Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/d05be59885f7e069b0595fda263af661bfdc5e45
Added .htaccess file to set Access-Control-Allow-Origin "*" for font files bug #790806

Comment 14

[Anthony Ricaud (:rik)]

$ curl -I https://www.allizom.org/media/fonts/OpenSans-Light-webfont.woff\ |grep Access
returns nothing.

Jake: Is the Apache instance for static files configured to execute those .htaccess?

Comment 15

[Jake Maul [:jakem]]

Sorry about that... indeed, it seems Apache was not respecting .htaccess files in there. I've added this, and it works on staging now.

Looks like the file doesn't exist on -dev though... different branch, for a guess.

I've set this same config up on prod, so this should work as soon as this .htaccess is deployed to prod. (+/- 30min from now, depending on puppet propagation).

Comment 16

[Anthony Ricaud (:rik)]

This has been pushed to production.

Comment 17

[Ben (:bensternthal)]

Verified on prod.

Note we may have to do additional tweaks for tabzilla outside of the font but we should track those elsewhere.

Comment 18

[raymond [:retornam] (inactive)]

HTTP/1.1 200 OK
Server: Apache
X-Backend-Server: bedrock1.stage.webapp.scl3.mozilla.com
Vary: Accept-Encoding
Content-Type: text/plain; charset=UTF-8
Date: Mon, 24 Sep 2012 17:05:48 GMT
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
ETag: "f57c"
Last-Modified: Thu, 13 Sep 2012 17:21:08 GMT
X-Cache-Info: caching
Content-Length: 62844