Posts: 855
Threads: 238
Joined: Nov 2015
Reputation:
96
I'm working on the mechanics portal, and was wondering if and how we can set the max session time for a webservice session. Some reports can take up to 40 minutes to fill out, so the session could expire during the filling of the form.
Posts: 855
Threads: 238
Joined: Nov 2015
Reputation:
96
Seems cool, but I've no experience with applying diffs, could you give a few pointers?
Also, I'd need to update my client library to use this new functionality right?
Posts: 3,564
Threads: 36
Joined: Apr 2014
Reputation:
49
Yes, this works on any coreBOS install.
The $exptime parameter is minutes and it gets converted into a unix timestamp, so, yes, you can set any unix timestamp in the database table.
Joe
TSolucio
Posts: 3,564
Threads: 36
Joined: Apr 2014
Reputation:
49
12-22-2016, 06:25 PM
(This post was last modified: 12-22-2016, 06:25 PM by joebordes.)
I was just debugging another issue and went to create a global variable. I saw these two: 'WebService_Session_Life_Span', 'WebService_Session_Idle_Time' which got me thinking about this thread.
I had a quick look and it turns out that these are the real way to extend the webservice session life span. The patch I shared on the gist extends ONLY the time you have to log in. In other words the time that the authtoken getChallenge returns is valid. Once you have logged in you are given a sessionid which is what you use for the rest of the calls. The life of this sessionid is controlled by the two global variables above and are what will permit you to keep connected to the service.
The documentation on the global variable module says:
WebService_Session_Idle_Time:
Maximum life span that a session should be kept alive after the last transaction. Default is 1800 (seconds). That means that after each access to the service the life of the session is set to 1800 seconds, so you can keep the session open just by accessing under this time.
WebService_Session_Life_Span:
Maximum life span of a webservice session. After this time the session will be destroyed even if it is being kept alive. Default is a day. This is the one you want to change in your install.
Joe
TSolucio
Posts: 855
Threads: 238
Joined: Nov 2015
Reputation:
96
That's what I suspected: I did some tests and it turned out that I was able to do updates when my session should have been expired and vice versa: not being able to update when I should have been allowed to. I checked the docs and was amazed that the challenge set the session expiration in stead of the login, but it seems that wonder was just.
Good to have you around again, thanks for the GV's. I think I need the other one though "Session Idle Time". The form the mechanics need to fill can take more than 30 minutes (1800 seconds) to fill, and after that the update fails and login is displayed. They will never be logged in more than a day, and there will be no issues when they accidentally try to do so.