forced log off due to inactivity (on-premise 6.12)-1530047296

Joe,
The functionality was removed with DocuWare 6.5. I am looking into remnants of it remaining up until 6.11. It might be that there is a setting in a config file that is controlling your timeout. I seem to recall a value of 10 minutes which is close enough to your 12. Nevertheless, it certainly is not there in DocuWare 6.12.

Phil

Thank you both for assisting in gaining some clarity on this issue.  Are there any workarounds for this in 6.12 (perhaps through SQL) or is it available in 7 or is there a plan to add this session timeout feature back in the next version?  I'm confused as to why this would be removed.

Mystery solved. From 6.5 to 6.11 there is a setting in one of the config files that defines many session parameters. In particular there is a session timeout setting. The default for this setting is 10:00 minutes, which correlates close enough to Joes experience. Now, with 6.12, this setting still existsin the file but it is clearly ignored by the platform engine. Therefore, there is really nothing that can be done from our side.

Phil Robson
Senior Director Support Americas

Phil,

Thanks for this truly definitive answer! What is the config file, by chance? I am not thinking I would ever need to change that setting, but it would be nice to know.

I also assume IIS needs to be bounced after changing the setting? I might play around with it just to confirm things act the way I think they should.

Sorry to hear 6.12 is out of luck -- I fear we may need to stay "left behind" even longer after hearing the timeouts don't work in 6.12 the way they do in 6.11. I share the lament of womdering why this was changed. Control over timeouts seems like a reasonable control to have, at least for on-premise work.

Thanks,

Joe Kaufman

Oh, and 10 minutes is exactly my experience. The extra two minutes is a built-in grace period for connection instances. Even if you issue an explicit "LogOff" while using the SDK, for example, the license expiration does not occur for an additional 120 seconds. Though, that may be the IIS 120 second time-out in play -- not sure.

Thanks,

Joe Kaufman

DocuWare.Platform.web.dll.settings.

  <CacheExpiration CleanupPeriod="00:00:20" Session="00:10:00"

Phil

Phil,

Thanks! Yes, we are definitely set to 10 minutes in that config file.

Thanks,

Joe Kaufman

I see that there has been a ticket open for this issue since 2015 and DW's response is officially we will add it to our collection of ideas.... That does not sound like it is being taken seriously.  In search of a solution I am taking a look at user sessions in the database. Ultimately, we will write something that identifies users based on inactivity, but in order to test it we used the simple syntax below and it worked as a way to boot users, by userid in this test scenerio.  I'm writing here to see if there would be any issue with this method as a workaround for the no session time out problem that will exist in 6.12 and beyond.

delete FROM [dwsystem].[dbo].[DWClientLicense]

where uid = <<specific user ID>>

Jason,

Nifty solution. I will be eager to see what support says about that sort of behind-the-scenes manipulation, and obviously such code may break between versions.

I imagine DocuWare let the issue fall off the back burner when they changed to named licenses. Perhaps the main focus was on concurrency, not on basic workstation security. That's a shame, because I don't see the downside to offering an auto-logout capability. It doesn't seem like DocuWare would have to compromise on anything to keep that functionality available, even if it were off by default (or even hidden in a config file).

Thanks,

Joe Kaufman

While I applaud your creativity, that is not a solution for a session timeout. Firstly, you do not know if the session is idle from the licensing table. Therefore you run the absolute possibility of corrupting data. Users sessions are tightly tied to the background processing - particularly in versions prior to 7. If you kill a client license in this manner, and the user has document writes active at the time it will kill those dead. The result could be anybody's guess.

I cannot stop anyone from doing this, but understand it is at your risk, not DocuWare's. I hope never to see a Support Request as a result of this cavalier approach.

Phil Robson
Senior Director Support Americas

Phil,

It would seem desperate times call for desperate measures, though. What else is one supposed to do if a customer requirement states that all connections to various resources (such as DocuWare) need to have timeouts built in for security? I don't think it is DocuWare's place to dictate what clients want to do in that regard. And at over 200 votes, the "user voice" is definitely saying this needs to be addressed, even with named licensing now being the case.

Judging by Jason's posts here, I have no doubt he wouldn't be so "cavalier" unless there was no other option. Unless you prefer the final option to be to dump DocuWare for a tool that supports this client need -- that's always an alternative, I suppose.

Thanks,

Joe Kaufman

Joe,
With respect, I have just clearly described how dangerous that method is on a DocuWare system  - specifically prior to DocuWare 7. Whether Product embraces the request is not my call. I simply support the product as it exists. For sure, I voice my opinion, but my opinion is no different from any user. It is taken and weighed in context. As you see in this forum thread, the Product Owner has made his comments.
My point is this, taking this approach is dangerous. What is more important? Your data or a session timeout? In most security requirements that I have read expect the computer to be locked as a priority - not timeout every session to every application.

So I don't see it as desperate times for desperate measures at all. And please don't try to bully me by suggesting that I may prefer that users dump DocuWare.

Phil Robson
Senior Director Support Americas

Phil,

I apologize for the way my tone came off -- I didn't mean to sound bullying; and by "you" I mean DocuWare, not you personally.

In my opinion, when a customer demands something, that resides on the spectrum of "desperate times". It is not DocuWare's call -- it is the customers'. I'll put it this way: where I work, if a customer asks for something, we do it unless we have a very good reason not to that we can help the customer understand. Otherwise, the customer goes somewhere else. It would probably be worse if we said we listened to the customer's voice, hundreds of customers told us what they needed, and we ignored it. You ask which is more important, data or a timeout -- I feel you are missing the point. Over 200 customers are wondering why data integrity and session timeouts need to be mutually exclusive.

I am not sure who the Product Owner is on this thread. Tobias? There is nothing to indicate his status if that is the case, so I honestly didn't know we were hearing from a "Product Owner" (I always thought Tobias was a support person like yourself). Not sure it matters, though, since his responses stopped coming even after people continued to explain their business-case need.

I agree that a comprehensive workstation lockdown SOP would be better for end-users overall, and named licenses cover concurrency issues, but that doesn't change the fact that the customer is always right. That is, unless DocuWare can more clearly explain the downside of keeping the timeout solution in play -- something no one (not even a Product Owner) has done yet.

Thanks,
Joe Kaufman

Phil,

First, thanks for the quick and detailed response. That's why I asked the question before implementing this approach.  Now if we could just harness that energy for a non-solution into one for an actual solution perhaps we can be more productive. Session time out was removed and not mentioned in the changes from 6.11 to 6.12. I'd say that's pretty cavalier.  DW didn't shift to named licenses they still sell concurrent but with a major price increase. This would suggest to me that concurrent licenses shouldn't be losing features like session time out. In any case, it looks like I'll be looking for a solution via browser, such as building an extension that closes tabs on the DW URL due to inactivity, that is if I cannot use PowerShell to manipulate URL-specific browser inactivity.

Here's the "idea" for bringing back session time out from 2015 with 205 votes.

https://docuware.uservoice.com/forums/230570-client-english/suggestions/...