Discussion board where members learn more about Qlik Sense Installation, Deployment and Management.
I have a Qlik Sense environment with IIS reverse proxy and a custom authentication (ticketing) module. The problem is that the TargetId (and thus TargetURI) that Qlik Sense provides to the authentication module uses the URL that the IIS reverse proxy uses to access Qlik Sense and not the URL that the end user uses when accessing the IIS reverse proxy.
Any ideas how to configure the reverse proxy setup so that the ticketing works correctly?
e.g. the user accesses the reverse proxy using “https://reverse.proxy.company.com/hub” which passes the request to Qlik Sense at the address “http://sense.internal:8080/reverse/hub”. The request is then forwarded to the authentication module at “https://authentication.company.com” with a TargetId corresponding to a TargetURI of “http://sense.internal:8080/reverse/hub”. When the user has authenticated a redirect is sent to the TargetURI which obviously is not accessible for the end user.
Same issue as mentioned. Changed our reverse proxy functionality to bigip (f5 waf) - and now the targetId references to the internal server address.
Could not find any difference in the initial GET request from browser (cookies, header, parameters etc.).
Any news about this? Could not find anything how QlikSense is generating the targetID.
From Qlik Sense November 2018, you can set the "X-Forwarded-Host" header (you can set in your reverse proxy rules to set this header on all requests) to the reverse proxy url so that the targetURI is built correctly.
For previous versions, I am afraid you will need to build the URI in your authentication module code as you have already done.
Thanks for your help!
Got it already working by setting the "Host"-header static to public DNS in our reverse proxy.
We did some debugging with proxy logs (debug level on), and could identify this header as the problem.
Sadly my last post here with the solution got lost.. 😞
We will try the "X-Forwarded-Host" too, because it seems like the better solution instead of rewriting a existing header.