the Session Cookie Header Name is very important in the virtual proxy as it identifies to Qlik Sense that the browser session accessing content is valid and authorized. Session Cookie Headers need to be unique for each virtual proxy so make sure your Session Cookie Header Name is something like X-Qlik-Session-A_ if A_ is really the prefix for your virtual proxy.
Now, as for what is happening with your attempt to get authorized via header injection. One thing that does not appear in the information you have provided is a cross-site scripting key (aka xrfkey) This key is necessary as a parameter in the url and a header value labeled X-Qlik-xrfkey if you are trying to connect to the rest apis. Without this parameter and value your request will be rejected. If you are trying to connect to the hub, it does not appear to be necessary, but you may want to test both scenarios.
When I'm testing header authorization for apis and general connectivity, I use the PostMan chrome extension.
Here is what my request looks like. It is a get request.
The response is the HTML and if you look at the cookies, the session cookie is provided.
Thank you very much Jeffrey. Yes I assigned a cookie name in my new dynamic header virtual proxy. Is that's enough or should I put anything in my reverse-proxy (or chrome extension) that (re)pushes this cookie back.
For xrfkey: Does Qlik Sense (QPS/QRS) need to recognize this key? Or just assign a header (say named X-Qlik-xrfkey) and value (say abcdefg123456789) and a URL get parameter with the same name and value: Say https://QPSserver:4243/_A?X-Qlik-xrfkey=abcdefg123456789
Where 4243 is the default Authentication port for QPS proxy.
I tried this above link https://QPSserver:4243/_A?X-Qlik-xrfkey=abcdefg123456789
I also tried it while alternating: Get vs Post requests, 4243, 4244. Still I receive 404 (wrong request).
Before that: Interestingly the cookie name in the 404 http response is the default virtual proxy (<>default, which is win authentication). So it seems that it isn't using new dynamic header virtual proxy "_A".
Interestingly also, after I exported the (server-root-client) certificates from QRS into my reverse-proxy server, when I first tried https://QPSserver:4243 it did ask me to pick a certificate (from a poped-up list), then when I picked the Qlik certificate (in one user I picked reverseProxy certificate, in another user I picked QlikClient certificate) then it gave me the 404 response and default-virtual-proxy cookie X-Qlik-Session, and it never asked me again for a certificate in following attempts. So it seems as if it has the Authentication port 4243 functional but didn't manage to find the good virtual proxy or the good certificate.
I seem to have been missing a configuration. Do I have to populate the virtual-proxy "integration" section with any values?
Thanks again for all help,
Amir, refer to the linked document http://community.qlik.com/docs/DOC-8135. From what you typed above the parameter in the url is supposed to be xrfkey, not X-Qlik-xrfkey. X-Qlik-xrkey is a header you add to the request. Yes the values for both the parameter and the header are the same.
If you are trying to connect to QPS or QRS then the xrfkey is a requirement. The Session Cookie value is returned upon successful authorization.
Here is a doc I created for properly configuring a virtual proxy and testing with postman and fiddler. This document is relevant for Qlik Sense 1.1.
As far as the certificate requests that pop up it's a result of increased security measures by modern browsers to prompt you to use a client cert when connecting to web sites through https. In IIS you can configure so that client certs are ignored in ssl connections.
For my test environment, I exported the certs from the Qlik Sense server and imported them into my local. I placed the root cert into the localmachine\trusted root cert authority location and the QlikClient into the localmachine\personal location.
Thanks very much! It definitely advanced my attempt. Now I can successfully http-request https://QPSserver/_A?X-Qlik-xrfkey=abcdefg123456789 (prefix now works in URL). I can also find the header virtual-proxy cookie: X-Qlik-Session_A, in my http response. However it works whether I put any "right" authentication header (CMI_Header: CMI\Me) or not. So it doesn't seem to be authenticating the UD\\UI.
Also before applying your settings, when I used to access https://QPSserver/_A from chorme-URL bar, it didn't recognize the header-virtual-proxy prefix, rather redirects me to:
But now a chrome-popup window is asking me for username/password, as if it failed on authenticating on Header params (CMI_Header: CMI\Me), and now looking for windows (default virtual-proxy) one.
Kind reminder: X-Qlik-xrfKey:abcdefg123456789 is added as header, and ?Xrfkey=abcdefg123456789 is added to URL.
Am I missing anything on configuring the linkage between the User directory (CMI_Header) and the header-virtual-proxy? Again "CMI_header" is the Header-Auth header name in my Header-Auth virtual proxy. "CMI" and "Me" are a sync'ed user-directory name and a userId in it respectively.
The users of CMI aren't showing anywhere (not in Users tab, neither in Lisenses&tokens>User access allocation section).
Thanks a lot again.
I don't know if your virtual proxy with the underscore in it is a good starting point. How about creating a virtual proxy called "test" or "CMI" and using that? Your header looks fine, but I don't see how you have it configured in Sense Server. One other thing, when requesting the resource it's going to be https://%senseServer%/CMI/hub not just https://%senseServer%/CMI because Sense won't know where to go.