8 Replies Latest reply: Sep 18, 2015 6:36 PM by Alexander Karlsson RSS

    How to delete session of a user

    Simone Cantoni

      Hi all,


      I am facing a problem with authentication: if my application connects more than 5 time to QlikSense, the server denied more accesses.

      I thought that deleting the opened session each time I make a new request to server could solve the problem, but I can't create the correct request to do that.


      The documentation only shows. /qps/{virtual proxy/}session/{id}


      I've tried with this request, without success:


      DELETE https://srv-msan:4243/qps/test/session/4a3e9856-e9a8-44be-b16d-532a6e1e65d2 HTTP/1.1


      I receive the 403 FORBIDDEN message as response.


      Anoyone who faced similar problem could help me? Do I have to write the request in a different way?


      Thanks in advance



        • Re: How to delete session of a user
          Onno van Knotsenburg

          If I understand correct, the limit of 5 is built-in to avoid breaching the licensing rules.


          If it is the same user connecting from your application to the Qlik Sense application, I wonder why it makes more than 1 connection to begin with.

            • Re: How to delete session of a user
              Simone Cantoni

              Thanks for the quick reply Onno,

              but I've tried that way because I saw that I cannot call more than once the same method in one session (for example the 'OpenDoc' method).


              I thought that create a session for each request could be a way...


              Maybe I am wrong, and there is another way to do that.





                • Re: How to delete session of a user
                  Alexander Karlsson

                  Your request to the QRS api is most likely missing certificates to authenticate it and it is missing the XRF key.

                  This article will help you connect, https://help.qlik.com/sense/2.0/en-us/developer/Subsystems/RepositoryServiceAPI/Content/RepositoryServiceAPI/RepositoryS…


                  However I don't think this will help you a great deal. To better understand the issue do you mind sharing some details around the app? Purpose, where it runs etc


                  For example if your app is purely for server side operations you can instead connect directly to the engine to avoid the 5 connection limit.

                  If you are connecting over the proxy do make sure you are closing the websocket connection after you are done, this should free up a spot among the 5 connections in the pool. I.e ws.close() and not getting rid of the session.

                  Your app should not really have to connect to multiple times to the engine, instead have a global connection that you keep open and re-use whenever a user requests a resource from QIX.


                  If you need user specific context I would heavily suggest you look into moving the communication layer away from the server and onto the client instead.

                    • Re: How to delete session of a user

                      Hi Alexander,

                      I'm a colleague of Simone.

                      We are very happy you gave a so quick and effective response since it is hard to find support on this topic that is extremely important to us.


                      As you suggested, with the XRF key we have been able to succeed with the session delete, but this doesn't solve our issue.


                      In the server_License_repository.txt log file we found 5 instances of "License.Repository.Repository.Core.Resource.RequestAccessTypeResource", with SessionCount starting from 1 up to 5 and then we receive "No available access type" at request number 6.


                      We are connecting from our Java Application (running on JBOSS) that is a multi user application, so the user context is important but we can't connect at the client layer, since we need our application to interact with Sense objects via Qlik API.


                      We use JAVA tyrus client for the websocket communication and to close the session we invoke the Session.close() method:


                      // open the connection

                      session = clientManager.connectToServer(clientEndpointConfig, serverURI);


                      // close the connection



                      Do you suggest in our case that it is a better approach to connect directly to the engine instead of going through the proxy?


                      We do not know how to reuse a global connection that we could keep open and re-use whenever a user requests a resource, since in our tests we found that in the same connection only one OpenDoc method can be invoked (it is not possible to open another app without opening a new session).


                      Maybe we are not using the right method to close the websocket connection, do you have any experience or examples on connecting using Java libraries?

                        • Re: How to delete session of a user
                          Alexander Karlsson

                          Ah that gives me a better overview of the issue. Let me get back to you as I'm out right now.


                          Also feel free to reach out directly to me at akl@qlik.com as it seems time is an issue and we might save some


                          Sent from my Windows Phone

                          • Re: How to delete session of a user
                            Alexander Karlsson

                            I haven't implemented something similar in JBOSS but we have a few successful implementations together with Jetty.


                            Most likely you are not authenticating the user and when you open a connection you are opening it as a single user/service account and then you will be limited to 5 connections. You should be able to determine this by inspecting the first frame that is being sent over the socket which will contain a OnAuthenticationInformation message that will tell you who you are authenticated as. This first frame should ideally contain the username of the user you are authenticating. You would want separate sessions anyway as it will share selection state.


                            Otherwise the limit is working as intended, it is there to prevent people from essentially just putting a proxy in front of the engine and serve up Qlik sessions to an unlimited amount of users while only consuming a single token.


                            So the process should go something like this,


                            1. Authenticate the user somehow, tickets/headers etc

                            2. Once authenticated a Set-Cookie response will be issued when requesting a resource from behind the QPS (for example if you have a ticket you can open a socket with ?qlikTicket=<ticket> and it will consume the ticket and send back a session cookie in the upgrade response.

                            3. Make sure the session cookie is part of the request that opens the socket, performs the handshake.

                            3.5 For Tyrus this means you need supply your own configuration class. http://chariotsolutions.com/blog/post/form-based-login-for-java-websocket-client/ Should help you with that

                            4. This will associate the session with the correct user.

                              • Re: How to delete session of a user

                                Thanks Alexander,


                                You clarified the process flow very well and we found our mistake.

                                Instead of reusing the session cookie for subsequent websocket sesssions we did a new user authentication each time, and this caused the issue.


                                We need to close websocket sessions and open new ones when we want to load a new Qlik document (since it is not possible to open more than a document per session as far as we understand how Qlik works), but reusing the same session cookies for subsequent websocket sessions solved our problem.


                                Thanks a lot for your support.