I'm trying to create a simple mashup hosted on another server, which includes, among other things, qsSimpleKpi extension objects.
The virtual proxy I'm connecting to is configured for SAML SSO, and for now I'm handling authentication by making sure a session is established beforehand and a session cookie is created.
This seems to be working for everything so far, except for loading fonts which are part of the extension. These for some reason trigger the whole authentication flow again, as if the session was invalid for them. This attempt at authentication obviously fails (this is SAML with POST binding, so I don't think it can even theoretically work in situations other than opening a full browser window or an iframe; in addition, I'm getting CORS errors because while QlikSense is sending appropriate Access-Control-Allow-Origin headers, those get stripped between all the redirects involved in SAML authentication).
Any idea why this happens and if it can be fixed somehow? (other than switching to another authentication method for the mashup...). I realize I can host only the fonts on mashup server and override their location in CSS, but I'd rather avoid that route and keep the extension nicely self-contained.
It looks like fonts referenced within css @font-face rules will always be requested anonymously (https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements), meaning no cookies or authentication headers will be passed with the request.
So, in case of a mashup hosted on a different server, call for a font always get redirected to authentication module. And in my case authentication is SAML, identity provider responds with something with no Access-Control-Allow-Origin header, and that's it.
Looks like Qlik will happily serve its own fonts from /resources/fonts in response to anonymous requests to, presumably, get around just this issue, however extensions using any custom fonts seem to be SOL.
We've ran into a similar problem with requests to sweep_*.json files from /assets/images/charts/animations. No cookie was passed with the request, and therefore Qlik server returned status 302.
Can you provide a sample of extension containing a font that triggers the issue ?
Please also let us know which version you are using.
In the theory, it should work (Qlik Sense should pass credentials on font requests)
What type of font is it ?
Has the type been added in the file extension whitelist ?
No, I did not find a solution. In the end we hacked the extension and changed the server from which fonts were served in extension's CSS (a very clumsy workaround).
FWIW I don't think it's a matter of Qlik not sending credentials. It's the browser that will strip credentials from a request for CSS font, because sending them would violate CSS font spec (linked on my second post).