Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
About "Webservice_Session_Idle_Time"
About the GV called "Webservice_Session_Idle_Time":
  • Does it matter to which user or group it is assigned?
  • Does it matter to which module it is assigned?
  • Does it matter if "in module list" is checked?
  • Does the category matter?

I'm trying to set the limit to a large number, since some of the portal work I've created can take some time. But still sometimes it logs out after a short period. Could I maybe create a JS AJAX call that just does a simple call to keep the user logged in?
Try this change and let me know if it is better:
diff --git a/include/Webservices/SessionManager.php b/include/Webservices/SessionManager.php
index cb88c0e..d2d6a47 100644
--- a/include/Webservices/SessionManager.php
+++ b/include/Webservices/SessionManager.php
@@ -20,7 +20,7 @@ require_once("include/HTTP_Session2/Session2.php");
               function __construct(){
                       $now = time();
                       $this->maxLife = $now + GlobalVariable::getVariable('WebService_Session_Life_Span',86400);
-                       $this->idleLife = $now + GlobalVariable::getVariable('WebService_Session_Idle_Time',1800);
+                       $this->idleLife = $now + GlobalVariable::getVariable('WebService_Session_Idle_Time',1800,'',Users::getActiveAdminId());

                       HTTP_Session2::useCookies(false); //disable cookie usage. may this could be moved out constructor?
                       // only first invocation of following method, which is setExpire
the record should be assigned to the admin user after that change, all the rest does not matter
I implemented the change (just copy/pasted the line) and running a test now in a test environment. I'll let you know.
Unfortunately this doesn't seem to have an effect. I set the GV to a very hgh value but still the connection terminates after about ten minutes.
I've created a small JS AJAX script that performs a very simple task (get the accountname for the first account) and set an interval of 5 minutes on this to see if this helps.
I remember having looked at the session lifespan a long time ago (when it was still vtiger CRM) and making a mental note that the whole session management was incorrect, to the point where the session was never expired.
So you can imagine my surprise to this discussion.
I got around to testing it today and I think I can confirm that it definitely does not expire.

I created a script that uses direct cURL calls to login. Then I get the sessionid and created another script to launch a query. I did this twice, once with the default value of 86400 and another with 60 in the maxLife global variable. Then I launched the query with no problem for over an hour. I shut down the laptop and turned it back on an hour later: both sessions were still valid and working.

Obviously, we will have to look into this and get it fixed, but in the meantime, you should be able to do what you want to do.

Here are the scripts:

let me now how it goes

Forum Jump:

Users browsing this thread: 1 Guest(s)