Anonymous public embedding with @qlik/embed-web-components on QAP (client-managed) — is it a supported combination?

[luis_pimentel]

Hi everyone,

We are working on a project that requires embedding Qlik Sense visualizations publicly into a Drupal portal, where end users are anonymous (citizens accessing a public institutional website — no Qlik accounts, no login).

Our setup:

• Qlik Sense Enterprise for Windows, on-premise, with a QAP (Qlik Analytics Platform) license
• Target CMS: Drupal
• Embedding framework: @qlik/embed-web-components (qlik-embed)

We have already run a successful proof of concept using qlik-embed on a standard QSE on-premise installation (non-QAP) with a WordPress CMS, including cross-domain scenarios. The embedding worked correctly once we configured the Virtual Proxy (allowed origins whitelist, SameSite=None, Access-Control-Expose-Headers: qlik-csrf-token). Authentication was handled by an active Named User session.

The problem: The real requirement is anonymous/public access — no Named User session, no login. When we try to use qlik-embed without an authenticated session, the Web Component attempts to connect but fails because there is no valid session context or token available. The component simply doesn't render.

We understand that the official Anonymous Access feature for qlik-embed (OAuth2 anonymous embed client) is Qlik Cloud only and not available for client-managed deployments.

Our question: Is the combination of anonymous public embedding + @qlik/embed-web-components + QAP client-managed officially supported? If so, what is the recommended authentication/session mechanism?

Workaround we are considering: We are evaluating a Virtual Proxy configured with header-based authentication, where a reverse proxy (e.g., Nginx) injects a static header on every request:

X-Qlik-User: UserDirectory=PUBLIC;UserId=anonymous

This would map all public users to a single Qlik identity, giving each browser its own session while no login is required. We are aware this is designed for trusted system-to-system integrations, not originally for public portals, and that the reverse proxy must strip any client-supplied X-Qlik-User headers to prevent injection attacks.

We are also considering JWT authentication as an alternative — generating a JWT token server-side (from Drupal) with a generic/random userId, which Qlik would validate against the Virtual Proxy. This seems more robust but adds backend complexity.

So, my questions are:

1. Is anonymous access via qlik-embed officially supported on QAP client-managed, and if so, how?
2. Is the static header workaround (X-Qlik-User: UserDirectory=PUBLIC;UserId=anonymous) a viable approach for this use case from a technical and licensing standpoint?
3. Is JWT with a generic anonymous userId the recommended path for on-premise anonymous public embedding with qlik-embed?
4. Are there any QAP licensing implications for anonymous access? We understand QAP is core-based and does not use Named User tokens — does it allow anonymous sessions at all?

Any guidance, official docs, or community experience would be greatly appreciated. Thanks in advance.

---

QSE for Windows, QAP license, on-premise, qlik-embed (@qlik/embed-web-components), Drupal CMS, cross-domain setup.

[alex_colombo]

Hey, could you please share your qlik-embed configuration? Did you try to set up data-auth-type prop as "noauth" or not passing the data-auth-type prop?

[luis_pimentel]

Hi Alex,

I am not able to paste our customer answer here, probably because there si some html code on it.

Please find it attached.

Thanks in advance

[alex_colombo · Accepted solution]

I made a quick tests against one of my env with QAP and anonymous access in place. Below the qlik-embed configuration which is working for me.

<script
	crossorigin="anonymous"
	type="application/javascript"
	src="https://cdn.jsdelivr.net/npm/@qlik/embed-web-components@1/dist/index.min.js"
	data-host="https://10.76.194.183/anonym"
	data-login-uri="https://10.76.194.183/anonym"
	data-cross-site-cookies="true"
  >
</script>

[luis_pimentel]

Many thanks @alex_colombo 

I can confirm is working for us as well.

Our customer issue was related to:

- reverse proxy configuration

- trying to host the html on a different domain than Qlik, wich

Regards

Luis