Skip to main content

Deployment & Management

Discussion board where members learn more about Qlik Sense Installation, Deployment and Management.

QlikWorld 2023, a live, in-person thrill ride. Save $300 before February 6: REGISTER NOW!
Showing results for 
Search instead for 
Did you mean: 
Partner - Creator
Partner - Creator

Reverse proxy with custom authentication module - problem with TargetURI


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 “” 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 “” 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.



6 Replies
Not applicable

Dear Christian,

did you manage to solve this issue ?

Best regards,


Partner - Creator
Partner - Creator

No, we did not manage to solve this in a pretty way. We bult a URL rewrite into the auth module. Not nice, but got the job done.

Not applicable

We are also dealing with problem and are missing a good solution!


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.

If the issue is solved please mark the answer with Accept as Solution.

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.


Kind regards

Patrick Doerr