You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I did a few operator shifts this year, and I noted every operator complaining about getting logged out of IMS many times during their shifts. This can be majorly inconvenient when it happens during a busy shift.
The state of things now is that an IMS session will always time out within 1 hour of its start [1]. That value is set here in our code.
The easiest thing would be to bump that value up from 1 hour to 7 hours. That would cover any normal operator shift. I'm open to alternative suggestions. I just don't think the status quo is reasonable for operators (nor really for shift leads).
[1] Gratuitous details on sessionTimeout
The Twisted documentation says that the sessionTimeout "attribute gives the number of seconds a session may go without being accessed before it expires". That led me to believe that the session should be getting refreshed regularly when the user clicks around within IMS. However, that doesn't happen, because nowhere are we invoking Twisted's "session.touch()" or "session.getSession()", which we'd need to do to actually refresh the session.
That suggests an alternative solution, in which we start calling session.touch() sometimes. The issue is that because of all the automated calls that happen on event changes, we'd constantly be calling session.touch() on all sessions during event week, and a session would likely never time out.
The text was updated successfully, but these errors were encountered:
I did a few operator shifts this year, and I noted every operator complaining about getting logged out of IMS many times during their shifts. This can be majorly inconvenient when it happens during a busy shift.
The state of things now is that an IMS session will always time out within 1 hour of its start [1]. That value is set here in our code.
The easiest thing would be to bump that value up from 1 hour to 7 hours. That would cover any normal operator shift. I'm open to alternative suggestions. I just don't think the status quo is reasonable for operators (nor really for shift leads).
FYI @justfred @wsanchez @chaoticbear, please provide any input.
[1] Gratuitous details on sessionTimeout
The Twisted documentation says that the sessionTimeout "attribute gives the number of seconds a session may go without being accessed before it expires". That led me to believe that the session should be getting refreshed regularly when the user clicks around within IMS. However, that doesn't happen, because nowhere are we invoking Twisted's "session.touch()" or "session.getSession()", which we'd need to do to actually refresh the session.That suggests an alternative solution, in which we start calling session.touch() sometimes. The issue is that because of all the automated calls that happen on event changes, we'd constantly be calling session.touch() on all sessions during event week, and a session would likely never time out.
The text was updated successfully, but these errors were encountered: