w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.43k stars 656 forks source link

[css-fonts-3] [css-fonts-4] Font fetching in anonymous mode makes it impossible to link to fonts behind authentication #3194

Open mrbig opened 5 years ago

mrbig commented 5 years ago

This issue is to discuss this section in the specification: https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements https://www.w3.org/TR/css-fonts-4/#font-fetching-requirements

When fetching [fonts], user agents must use "Anonymous" mode

This is implemented in both FF and Chrome in a way, that no user specific headers including the Authorization headers are sent when requesting fonts from a different domain.

The leads to weird problems in some rare cases. Let's consider an application that is protected by basic authentication and serves css and font files from a cdn, like this:

www.example.com/index.html - links to css: cdn.example.com/example.css - links to font: cdn.example.com/example.ttf

Now this happens when user visits www.example.com:

  1. Auth dialog appers for www.example.com realm, then index.html is loaded
  2. Auth dialog appers for cdn.exmaple.com realm, then example.css is loaded
  3. Browser starts a CORS request for the font file, but without the authorization header => loading the font fails with 401 status code

Even if the user opens the font file directly in a browser tab and enters the correct credentials when returning to www.example.com the font won't load because of the request is anonymized in that context.

A few more discussions around this issue I've found online: https://bugs.chromium.org/p/chromium/issues/detail?id=516192 https://stackoverflow.com/questions/34811208/my-css-cant-load-web-font-woff-files-located-on-an-other-httpsauth-server-cors

Please let me know if this behavior was intentional in the spec, or make it clear if current implementations aren't working as excepted.

Thank you

css-meeting-bot commented 5 years ago

The CSS Working Group just discussed Font fetching in anonymous mode makes it impossible to link to fonts behind authentication.

The full IRC log of that discussion <AmeliaBR> Topic: Font fetching in anonymous mode makes it impossible to link to fonts behind authentication
<AmeliaBR> github: https://github.com/w3c/csswg-drafts/issues/3194
<AmeliaBR> myles: Anyone knowledgeable about this? I don't understand it fully.
<AmeliaBR> florian: I can introduce, but I'm not an expert either.
<AmeliaBR> Rossen_: This issue has been open 6 months. Can we at least acknowledge that this is an issue we should be trying to address?
<AmeliaBR> … We need to distinguish whether it's difficult or whether we don't care. Encourage engagement on GitHub.
<AmeliaBR> florian: The font spec requires that when we fetch the font we use anonymous mode for fetching. If the font (along with the rest of the website) requires authentication cookies, then the font is blocked because anonymous makes it look like you're not logged in.
<AmeliaBR> … Did we do this on purpose?
<fantasai> florian: If not can we fix it? Because it's causing problems
<fantasai> AmeliaBR: this ties into discussion on url modifiers and other loading modifiers in CSS
<fantasai> AmeliaBR: I think it's something we can fix given we'll have a way to control cross-origin authentication level
<fantasai> AmeliaBR: We've talked about upgrading image() to use CORS with or without authentication
<fantasai> AmeliaBR: Another way is for fonts and a few others that we do currently say Anonymous
<fantasai> AmeliaBR: a cross-origin modifier can be used to upgrade to fetch with authentication
<fantasai> florian: Something missing to me is use case for putting the fonts behind the login
<fantasai> AmeliaBR: You covered the use case: when your entire website is behind authentication
<fantasai> Rossen_: My ask is that ppl interested in the area please engage with the issue on GH and let's see if we can make some progress there
AmeliaBR commented 5 years ago

The general issue on crossorigin modifiers for CSS assets is #1603