Skip to main content
Announcements
Global Transformation Awards! Applications are now open. Submit Entry

Need to Know: Embedding Qlik Analytics and the End of Third-Party Cookies

84% helpful (5/6)
cancel
Showing results for 
Search instead for 
Did you mean: 
Jeffrey_Goldberg
Employee
Employee

Need to Know: Embedding Qlik Analytics and the End of Third-Party Cookies

Last Update:

Jan 9, 2024 1:32:24 PM

Updated By:

Jeffrey_Goldberg

Created date:

Jan 5, 2024 4:57:03 PM

Web browsers blocking third-party cookies impacts embedded analytics

In case you missed it, Google finally set Q3 2024 as the date for 100% blocking all content relying on third-party cookies rendered on web pages in Chrome. At Qlik, the date is not a surprise to us, and to all our customers who embed Qlik Sense, we appreciate your collaboration and patience. We’ve been working hard for two years to prepare our products to handle this change and the impact it has on your end users. Here’s some additional information we believe will help you understand the changes Google and other browser makers have made to their software and how to configure Qlik Cloud and Qlik Sense Enterprise Client-Managed to keep embedded analytics working smoothly with your web applications and mashups.

Browser changes

Browser makers are handling third-party cookie blocking in different ways. You can learn more about the browsers Qlik supports for Qlik Cloud and Qlik Sense Enterprise Client-Managed and how those browsers handle third-party cookies and the changes they’re making by reviewing Google's Privacy Sandbox pages, and Saying goodbye to third-party cookies in 2024. Here’s a quick recap for popular browsers:

  • Google Chrome: 100% of all third-party cookies will be blocked beginning Q3 2024. Today, Chrome is blocking 1% of third-party cookies in Q1 2024 according to their documentation, and it’s possible your company is enforcing third-party cookie blocking through automated browser settings management. So blocking Qlik embedded content is likely going to be a surprise without mitigation
  • Apple Safari: By default, the “Prevent cross-site tracking" setting is on, blocking all third-party cookies Safari for Mac and iOS.

Microsoft Edge & Mozilla Firefox do not currently break Qlik Sense embedding with default privacy or cookie configurations. Please refer to your browser provider for up-to-date information.

Mitigating third-party cookies

If you're embedding Qlik Sense into a web app or mashup, we recommend reviewing configurations and deployments end-to-end to ensure they implement best practices for operating in browsers blocking third-party cookies. By default, Qlik Cloud and Qlik Sense Enterprise Client-Managed utilize cookies to maintain an authenticated session between the client browser and Qlik services. Because of the browser changes your solution may not display embedded content. To mitigate this issue, you can augment your solution to change how Qlik maintains an authenticated connection from your application to Qlik Sense.

  • For Qlik Cloud: use OAuth clients to connect your web application to Qlik.
  • For Qlik Sense Enterprise Client-Managed: use a domain certificate so the web application and Qlik server use the same domain.

Qlik Cloud (SaaS editions)

Since release at the end of 2022, embedding analytics from Qlik Cloud is possible using OAuth2 tokens for a cookie-less session. You can learn more by reading our authentication best practices for Qlik Cloud.

Using OAuth2 works with many of our embedding frameworks, including the new qlik-embed framework, capability APIs, nebula and enigma, and the various SDKs.

If you are using classic embedding libraries like the app integration and single integration APIs, you can use a session cookie proxy for Qlik Cloud, although you should look to use qlik-embed where possible in place of these experiences.

 Qlik Sense Enterprise Client-Managed

The easiest way to mitigate third-party cookie blocking is to use a trusted domain certificate issued by a valid certificate provider. This will enable your web application and the Qlik Sense server to share the same root domain name (e.g. example.com). Therefore, there will be no third-party cookie issue with embedded content between the Qlik server and your web application. The typical implementation uses a wildcard certificate so that your web application and the Qlik Sense server share the same root domain but have their own subdomain names. For example, with a wildcard certificate “*.example.com”, your web application would be “web-app.example.com”, and your Qlik server would be “qlik-sense.example.com”.  You can learn more about adding a signed server certificate on help.qlik.com.

Comments
stefanstoichev123

Thanks for sharing Jeff!

Do you have any link (from Google's documentation somewhere) that explains the same domain certificates "workaround"? Not sure that i can find it but want/have to share this info with a client.

Thanks!

Stefan

rva
Partner - Contributor III
Partner - Contributor III

Hi @Jeffrey_Goldberg !

 

How will this work if I have an IFRAME Integration of Qlik Sense On Premise with Microsoft SaaS CRM?
We are using a OAuth-Authentication there as well, but we will not be able to have "SSL Certificate" that matches the Microsoft SaaS CRM domain.

 

Thx,

Roland

Sonja_Bauernfeind
Digital Support
Digital Support

Hello @rva and @stefanstoichev123 Let me look into this for you.

All the best,
Sonja 

Jeffrey_Goldberg
Employee
Employee

@stefanstoichev123 , 

not sure what you mean by workaround here. In the case of on-prem Qlik Sense, using a wildcard certificate or a specified subdomain certificate for your Qlik Sense proxy that has the same base domain should mitigate 3rd-party cookie violations.

For example, I want to embed Qlik Sense into my own product's web page. The address for that web page is www.jeffwecan.com.

I have obtained a wildcard certificate from a valid (trusted) certificate authority (e.g. digicert) so I set up that certificate as the certificate on the web server hosting www.jeffwecan.com.

I import the trusted wildcard certificate onto the Windows server hosting the Qlik Sense client-managed proxy. I add the thumbprint into the configuration for the proxy in QMC, and I change the hostname of the Qlik Sense client managed server to analytics.jeffwecan.com. 

Now when I visit www.jeffwecan.com with embedded content from analytics.jeffwecan.com, both sites have the same domain, therefore, there is no third-party cookie.

As far as I know, this behavior should not change. At least, I have not read anything that browsers are not supporting this behaviour.

Jeffrey_Goldberg
Employee
Employee

@rva ,

I have to learn more about OAuth in client-managed. I do not know if using OAuth in client-managed returns a cookie or gives you a session token. If it's the latter, then certificates may not be necessary. However, depending on how the OAuth capability is implemented in client-managed, you may need to add allowed origins and proper callback URLs to ensure a proper handshake between the embedded content from Qlik and the host application (MSFT).

From my reading and research, iframes and OAuth coexistence is not easy. So I suspect even though you're performing an OAuth "authentication" to client-managed, it's returning a cookie. If this is the case, then it's possible the browser change will create a breaking change with your integration.

rva
Partner - Contributor III
Partner - Contributor III

Hi @Jeffrey_Goldberg !

 

Thanks for the update. Any options to test this in advance? Is there a hidden setting in Chrome to enable the new behavior, or do we have to wait until the Chrome version is released?

Thx,

Roland

jstar
Contributor III
Contributor III

Hi,

we did some research. 

With firefox you can switch of  "Third-Party Cookies" or all cookies and test your environment.

@rva 
"How will this work if I have an IFRAME Integration of Qlik Sense On Premise with Microsoft SaaS CRM?"

It is not going to work. (unless you build up some reverse-proxy stack, but this is not a real solution.)


Qlik Sense works with Websockets, even with an i-frame you build up a direct websocket connection to your qlik sense env.

Without a session cookie qlik sense is not going to build up this socket. You can test it with deactivating all cookies, you can't open qlik sense itself.

Therefore qlik is not working without cookies. In an i-frame the cookie of your qlik sense env is handled as a third party cookie and therefore it is blocked.

To summarize: 
Qlik miss a solution for embedded-analytics currently.

Using some shared wild card certificate constellation as a cookie hack and call it embedded analytics is not a real world scenario or secure. 

Also the cloud solution, building up a "session cookie proxy" is more like a workaround.

Is there a solution?
Yes, but qlik needs a deeper implementation of it... (token header for example)

rva
Partner - Contributor III
Partner - Contributor III

@jstar !

Thanks for your feedback!

This sounds bad. So no real solution for all MS CRM/Salesforce Qlik-IFrame Integrations?

@Jeffrey_Goldberg : can you take a close look at this.Anything R&D can do for us? "Firefox" would be a workaround until they adapt their behavior as well? 

muhammadraza
Partner - Creator
Partner - Creator

Since major browsers like Chrome are going to stop 3rd party cookies there is an article from Qlik to address this issue (https://community.qlik.com/t5/Official-Support-Articles/Need-to-Know-Embedding-Qlik-Analytics-and-th...). I was wondering what will be the impact where clients are embedding Qliksense charts through iframe in their own web portals e.g. Sharepoint. We have such client who are embedding Qliksense charts through iframe into their website but both sites urls are different. How this problem could be tackled in this scenario.

Yves_Jezequel
Contributor II
Contributor II

Hello Muhammadraza, it looks like we will have this problem, in Chrome pages with embedded iframes work well in Chrome if allowing 3rd party cookies which is won't be possible forever. Jeffrey if certificates are already in use with different domains is there a not so easy solution other than (which I suppose would work) install an extra consumer node using a certificate with the same suffix as the domain where the Sharepoint pages are published or change the certificate (and the url) for the server?

Version history
Last update:
‎2024-01-09 01:32 PM
Updated by: