Session duration for webservice

[Guido1982]

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.

[joebordes]

Try this change:

https://gist.github.com/joebordes/8fea7c827df3bcec65c717f5ed104a44

[Guido1982]

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?

[joebordes]

(12-19-2016, 07:57 PM)Guido1982 Wrote: Seems cool, but I've no experience with applying diffs, could you give a few pointers?

copy the file to the top of your install and execute this command

Code:

patch -p 1 < WebserviceDefineExpireTime.diff

the patch command knows how to read the format and apply the changes for you. In general, the lines that start with minus have to be deleted and the ones with plus added, usually it is the same line with some change.

In this case you also get a completely new file with some SQL that you need to execute.

(12-19-2016, 07:57 PM)Guido1982 Wrote: Also, I'd need to update my client library to use this new functionality right?

Yes, you will have to adapt the getChallenge call

[Guido1982]

Quote:patch -p 1 < WebserviceDefineExpireTime.diff

Would this also work for a non-git controlled version?

---

In the 'get_challenge', we could set an expirytime. Would be a UNIX timestamp I assume?

[joebordes]

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.

[Guido1982]

If I were to execute

PHP Code:

INSERT INTO `vtiger_ws_operation_parameters`(`operationid`, `name`, `type`, `sequence`) VALUES ((SELECT `operationid` FROM `vtiger_ws_operation` WHERE `name`='getchallenge'),'exptime','string',2) 


in phpmyadmin and alter the file '/include/Webservices/AuthToken.php' (the vtws_getchallenge function), this would basically be the same as executing the diff right?

---

Wait, I see. The query adds a parameter to the getchallenge function. How cool, never knew you could use a query within a query.

---

I have a VPS that runs ubuntu server to play with and learn bash like commands, but no time to actually get to it..

[Guido1982]

It worked. I installed log4php on my portal and setup a log message:

Code:

22-12-2016 15:04:11 method: __doChallenge message: Login by Someone, expires at 16:04:11

Obviously I set the expiration to an hour.

[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.

[Guido1982]

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.