Skip to main content
Announcements
Live today at 11 AM ET. Get your questions about Qlik Connect answered, or just listen in. SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
kuba_michalik
Partner - Specialist
Partner - Specialist

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.

Labels (5)
5 Replies
kuba_michalik
Partner - Specialist
Partner - Specialist
Author

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.

Argh.

alextimofeyev
Partner - Creator II
Partner - Creator II

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.

eric_careta
Partner - Contributor III
Partner - Contributor III

hi everyone!

I have the same trouble, do you find a solution?

Thanks!

Damien_Villaret
Support
Support

Hi @eric_careta 

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 ?

https://support.qlik.com/articles/000059155

If the issue is solved please mark the answer with Accept as Solution.
kuba_michalik
Partner - Specialist
Partner - Specialist
Author

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).