We have noticed recently that we are getting logged out of Perspective sessions at random intervals. We had thought perhaps it was getting driven by multiple users logging in or errant auto logout code we had implemented before the activity time out but none of that seems to be in play. Sometimes it can happen 2 minutes after logging in or it can stay for hours or more. We are assuming it is somehow related to some kind of network drop but are unsure how to trace it. What kind of activity could cause a session to lose it’s authentication? Are there any tools or items in the log we can turn on to track the culprit? Nothing seemed to stand out in the logs.
What version of Ignition are you seeing this issue on?
8.1.1 nightly
Ok. I don’t have troubleshooting recommendations for you, but I’ll notify someone about this thread and see if we can get that question answered.
In the meantime, I should point out that the current nightly is not truly current with the state of ignition.
The way our development flow works, the ‘nightly’ is generally the ‘current’ state of our development branch, unless we are staging candidates for the next release. When in the middle of a release candidate, our ‘bug fixing’ and testing focus is generally on the pending release’s code branch. We periodically bring these changes into the ‘nightly’ branch, but when we do that is variable. Following a release, all changes are then brought into the nightly branch, at which point it is fully up to date with the previous release in terms of features and fixes (as well as may contain new untested features or fixes that we don’t feel belong in an RC).
That’s a long way of saying “leading/nightly’ branch may not have all the things that have been fixed in ‘release candidate’”. So my suggestion for now would be to try the release candidate, as it likely has fixes and improvements that are not yet in the nightly.
That all said, I’ll get some eyes on your post and see if anyone has thoughts.
Just curious: does you project require authentication in order to access it?
You might want to try and reproduce the problem in a more isolated way if possible. For example, maybe leave only one authenticated client session open for a while and see if that one session becomes unauthenticated after a while.
Look for gateway logger perspective.ClientSession messages such as Session timed out or WebSocket disconnected from session (set this logger to debug for these messages). These messages could indicate that your client is disconnecting for some reason from the gateway (maybe due to network issues) and after a while, the session is timing out and getting removed from the gateway (if a reconnect does not happen in a timely fashion).
If a project update occurs and the project update includes changes to the project’s IdP or the permissions required to get into the project, this could be a source of a logout. Or if any of the IdP’s settings in the Gateway Web Interface > Config section was changed, that could also trigger a logout.
You might also try turning on auditing on the project. Look for audit events with name Web Auth Status Change which could give you some clues as to when authentication state changes on the perspective session and what the state changes to (including the username, security levels, etc).
1 Like
I’m a colleague of the author of the original post. In following up on this I found the following debug message when the client logged out. It had stayed logged in for about 11 minutes with only 1 client (and 1 designer window) open. I did change views on the one client and also opened an additional client (not logged in) shortly before the logout occurred (around 1 minute before the logout). I don’t know if that is a coincidence or not. When it is logging out I am not getting any warning on the screen for the Grace Period.
I did a second test, this time with two clients open the whole time (designer also still open), but only logging in on one client. It remained logged in for 23 minutes with no issues. During this time I did not change screens on either client. At 23 minutes I changed views on the client not logged in. The logged in client stayed logged in for 5 minutes. I then changed views on the logged in client. The client then logged out after 1 minute. From this it seems like it isn’t a coincidence.
Did an additional test - same clients open and the designer. This time I logged in (same client) and then change the view right away. The client logged out about 1 minute after the view change.
I did one final test with just one client open and it logged out about 1 minute after changing the view again. Seems very consistent.
Just to be clear, inactivity logout for the inherited project and for a sub project whose views get used in the main project were both at 60 minutes and the actual running project is turned off, but it is at 1 minute:
Upon noticing this I changed the 1 minute to five minutes, but that made no change. Then I re-enabled, saved, and disabled it (at 5 minutes still) so see if I would be logged out at 5 minutes. I was!
To test and see if the sub project or inheritable project had any effect I turned their logouts to off, but the problem persisted. It appears that the enable checkbox on the inactivity property is not working properly. It disables the grace period message when off, but you still get logged out. Additionally it only seems to take effect if the views have changed at least once since logging in. I tested this when the inactivity was enabled and it did not exhibit that same issue - it would properly log me out after 1 minute even if I did not change views after logging in.
Thank you for the helpful information. I was able to reproduce the bug on my end. Looks like the problem is exactly as you describe: disabling the idle timeout in project properties does not actually take effect. I’ll file an internal ticket to get this fixed.
2 Likes
The fix for this issue should be in the 8.1 early access builds as of a few days ago. It should also be in 8.1.1-rc1. The fix ensures that the inactivity timeout is truly disabled when the “Enabled” property is unchecked.
Having similar issue/behavior in 8.0.16. Is this the same thing? Note sure if this was an issue since the Inactivity feature was introduced.
Can I just enable inactivity with a long timeout as a temp fix until I can update to 8.1.1?
Not sure if you are seeing the same thing or not, but yes you can work around the issue by setting the timeout to a large number - just keep it less than 35,792 because there is another bug we fixed with this one which caused the timeout to overflow to a negative number if set to this value or higher.
1 Like
It is. I set mine to 999mins