I see two different things here. First is authentication (who can get to the reports) In an Active Directory environment, this are NTFS permissions given to a username/password pair. Second is authorization (what you can see in the reports) usually set up by means of section access.
When you log in to the access portal, you are using the first one, so the user is able to get to the server and has enough permissions as to see the documents available. You can set up how to get this authentication in the QlikView Enterprise Management Console, System, Setup, QlikView Web Servers, click on yours and set up the web form instead of the default. That web form will pass to the server the username and password provided, that must match with an existing user in your security directory.
Hope that helps.
Thanks a lot for your reply,
I agree with you and confirm that I understood the difference.
So there is no way for me to access the Access Point lets say with Login Steve and Pass 123
and access the report directly with Steve and Pass 123 (for the section access).
I will have to write my login and password twice for Access Point and Section Access.
That work has to be done by the browser. A clear example is what happens with IE and NTFS permissions. If you have configured your server to get directly to the Accesspoint, you can configure your browser to use your current crendentials when prompted, which results that if you are granted permissions in the server, your logon credentials are so passed to the server so you are authorized authenticated.
The second step is to have the section access configured to read users as they are in the Directory, either hardcoded using an INLINE table, for example, or using the connector to read users from the AD. If this is the case, you are authorized, and your user exists in the section access, and as your logon credentials are passed on to the server, and they match one existing value in the section access, you are accessing "automatically" without being actually prompted.
So if your browser can pass your login credentials directly to a webpage (the web form mentioned above) and provided the same exact user exists in the section access, you will not be prompted.
However, if you are allowing QVP (meaning port 4747 open both inbound and outbound and both server and client), you can use a URL string using the user and password for the section access. It requires more tweaking, but my guess is that you can use the HEADER option under the Authentication tab in the webserver (QEMC) and specify the HEADER where you store the username and password, that might work. I have not had the opportunity to test it though.
The code above will work with the plugin only, since QVP is not supported by AJAX. The "qvp://" is only handled after installing the plugin, actually. Both USERID and PASSWORD mean the section access (authorization) fields, but they may coincide with the ones used to authenticate the user to log into the server.
If your users use AJAX, then the above doesn't apply, at least as far as section access is concerned.
It's a nice try anyway, and I'd thank you very much if you share your results with us.
Hope that sheds some light
It seems to me that you should be cautious using the password in the QVP URL. If this is done from a shared computer, keep in mind that the browser may cache the page, the URL may show up in the browser history, and it could be saved in a bookmark. These are all potentially serious security holes that you might want to be concerned about.