Qlik Community

Qlik Sense Integration, Extensions, & APIs

Discussion board where members can learn more about Integration, Extensions and API’s for Qlik Sense.


Problem loading extension fonts on a mashup

Hi all,

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.

1 Reply

Re: Problem loading extension fonts on a mashup

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.