We use Glyphicons fonts on our website for some icons and they seem to be getting blocked by CORS Policy when added through Marketo.
This is the error I'm getting in the Console in Chrome:
Access to Font at 'https://myurl.com/Content/Fonts/glyphicons-halflings-regular.woff2' from origin 'https://na-sj20.marketodesigner.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://na-sj20.marketodesigner.com' is therefore not allowed access.
Has anyone fount a way to allow bootstrap fonts through Marketo?
While using webfonts on Marketo LPs can come with a few frustrations, this situation seems like one you've caused yourself.
If you're serving fonts from a non-Marketo webserver, you naturally need to allow cross-origin loading from the Marketo sites (which include both *.marketodesigner.com and your LP domain). This is a setting to make on your side.
My first impulse is to tell you not to worry about this particular issue. It may only be an artifact of the way Marketo's Design Studio is designed to work.
The error you're reporting is coming from within the domain 'marketodesigner.com' which makes me think you're doing a preview. In my experience, very few of Marketo's previews actually work according to plan; if the only issue is you're getting the wrong fonts/icons in the form, it may not be worth the bother of fixing it.
If you want to try fixing it, you have to be able to control the headers sent by the source of the icon font. The server sending the font has to include the header "Access-Control-Allow-Origin:" in it, set in a manner to allow the cross-origin request.
And *that* is where the rub comes in. For example, in our own specific case, we have a custom subdomain created which refers to the Marketo server that serves our forms and the assets they consume. We have no control over that server and Marketo denied our request to set it to enable CORS. Ergo, we *always* get that same error you describe, as the marketodeisgner.com domain is not allowed to make those kind of requests from our custom subdomain. This means if you have no control over the configuration setting on the computer serving the icon font, then you're stuck, the error will be with you always. But the bright side of it is the error will only be present in the Design Studio previews, and not in the real form. (Plus, if you're as easily amused as I am you can get a chuckle every time you see it over the fact that Marketo's own policies not only cause the error but prevent it from being fixed.)
If your answer to "Can I control the headers issued by the server holding the font?" is "Yes," then you're in business. Sources of information, depending upon how much detail you want to get into:
I should note that some people are afraid of CORS because of security issues. It *does* open a wider attack surface in that all that is required is for the asset server to be compromised for all of its client servers to be compromised as well, so be aware of that as you decide whether you want to fix that error.
Hope that helps.
And *that* is where the rub comes in. For example, in our own specific case, we have a custom subdomain created which refers to the Marketo server that serves our forms and the assets they consume. We have no control over that server and Marketo denied our request to set it to enable CORS. Ergo, we *always* get that same error you describe, as the marketodeisgner.com domain is not allowed to make those kind of requests from our custom subdomain.
You're absolutely right, that's a well-known case. But if "http://myurl.com" means the zone apex http://example.com, doesn't apply here, since the apex can't be used as a Marketo LP CNAME.
Anyway, for a long time we've worked around the CORS issue w/r/t webfonts as Marketo assets. Our templates always detect if they're running in the editor and switch to a CORS-enabled gateway. Screenshot of the LP Ed w/Marketo-hosted webfonts:
Have to dig in to how you're doing that, because it never worked for us, including the preview of a test landing page (one I abuse all too often trying strange ideas out) I just checked a few minutes ago. Obviously it's not as simple as, "it works;" there's something more to it in the template code that I'm going to have to appropriate, er, study. Yeah that's the word, study.