QDT-Components and JWT Auth flow with Qlik Enterprise - Question

[eric-tsibertzopoulos]

I am running the following components in my environment:

• Qlik Server Enterprise v13.32.2 (June 2019)
• Qlik JWT Proxy configuration (userID and user directory mapping)
• QDT-Components v2.3.7
• Angular CLI 8.0 (with Enigma.js 2.4.0)
• I have a .net core Web API that issues signed JWT tokens with the userID Qlik Claim

Although my Angular app can make Enigma.JS calls and receive data from Qlik, after my JWT/Cookie Auth flow, the QDT-Component is spinning indefinitely trying to retrieve a KPI object by ID.

Is there a document that provides the Qlik Server to QDT-Component version compatibility?

Thank you

[yianni-ververis]

There should not be a restriction based on Qlik Sense Enterprise version.

Are you loading the component after your auth?

Can you screenshot and share the console errors?

[eric-tsibertzopoulos]

AppComponent Code:

Console:

[eric-tsibertzopoulos]

Updated Console Info:

[fkabinoff]

hmm...check the network tab. is the request for require.js including the session cookie?

[eric-tsibertzopoulos]

Here is the Network trace:

The cookie is set on the Browser:

The AppComponent is getting a JWT token form the Auth API, it then does a GET on ../jwt/qps/user with the Authorization header set to Bearer .....jwt..... The app then routes to page1 that contains the QDT-Compoent configuration and element tag.

Is the above Authentication workflow the problem? or the QDT-Component creation on the routed page1?

X-Qlik-Session-jwt is the default cookie name in the JWT proxy configuration. Do I need to change the cookie name?

[fkabinoff]

So you seem to have a good understanding of the flow but just to recap. You make a request with the token, you get back a set cookie header, which sets the session cookie. That looks like it is set correctly. You should not need to change the cookie name. All that matters is that the virtual proxy is looking for that cookie. You can run into issues if you have 2 different virtual proxies looking for the same cookie name, but that doesn't seem to be the case here. So cookie looks good.

Next thing that should happen, if you are using vizApi, which looks like you are, is the require.js file will be requested, which we can see happen in the network tab. Require.js is actually behind the /jwt virtual proxy, so if there was any trouble with the session cookie I'd expect this request to fail, but it does not. The product-info.json file failing later I don't think is the big concern here. There are some files that fail cross-domain, that may be one of them.

Then I see the websocket connection to QSE in network tab with 101, looks good, but when I look at your earlier post I notice the request to connect to the websocket was made but that failed. I think the next place to look would be the messages in the websocket.

[eric-tsibertzopoulos]

and

[eric-tsibertzopoulos]

Sometimes I have to do a GET on .../jwt/qps/user to get the cookie, Sometimes I GET it from .../jwt/hub/sense/app/--appID--

Should I always go to the .../jwt/qps/user endpoint?

[eric-tsibertzopoulos]

More traces:

[fkabinoff]

I'm beginning to think this may be a QSE bug. Require.js loaded, which means the session cookie is good. The websocket messages look good, looks like you are authenticated fine.

I'm on QSE November 2019 Patch 4 Update 1 and I get the errors in the image below when connecting to a virtual proxy that requires authentication on a different origin than QSE, but it still works. However, I know there was at least one version of QSE released that made an ajax request from the require.js file without setting withCredentials: true, so the session cookie didn't get sent with the request if it was made on a different origin, and it would break the whole thing.

I think we address 2 things here. First, what version of QSE are you using? And second, if you set vizApi: false in the qdtComponents options, and you just connect to the engineApi, does it work? If it does, that's basically confirmation of what I think is going on.

[eric-tsibertzopoulos]

I am running: Qlik Server Enterprise v13.32.2 (June 2019) QDT-Components v2.5.1

When I set the vizApi to False, I see message exchange in the WebSocket: SESSION_CREATED etc., but the Cookie is not set in the browser.

When I set the vizApi to true, the cookie is set, but I get ERR_CONNECTION_RESET for product-info.json, and the WebSocket lists ERR_CONNECTION_RESET

I do receive hypercube data from the same QSE instance, JWT-Proxy setup, and Auth flow when I make Enigma.JS calls (no QDT-Components dependency in the app).

[fkabinoff]

I believe this may be due to your QSE version, as I know the bug I'm referencing existed approximately around that time. In addition to the fact that not loading the vizApi causes no errors, and everything else seems to be working in the images above, I strongly suspect it's a bug in that particular QSE version.

[fkabinoff]

im closing this as i'm relatively certain this is not a qdt-components issue at this point. find me on qlik branch slack @fka if this is still causing you trouble after trying a newer version of QSE. i think the bug im referencing was fixed in a June 2019 patch, but id try September 2019 or newer just to play it safe

[fawazeez]

We were facing some what similar issue with vizApi as qAppPromise was not getting resolved. White listing the IP helped. For Local host i tried below in additional response headers Access-Control-Allow-Origin:http://localhost:3000 Access-Control-Allow-Credentials:true