Project:
View Revisions: Issue #54156 | [ All Revisions ] [ Back to Issue ] | ||
Summary | 0054156: Race-Condition - Deferred Login State Initialization During the Login Process | ||
Revision | 2023-12-18 18:12 by ablasco | ||
Steps To Reproduce | How to check sessionTimeout Case: In Chrome Developer Tools. - Add a logpoint in registerAutomaticSessionTimeout() method and review Login SessionID inside of it. "IsLoginWindow ", OB.App.View.isLoginWindow() - In login window , this method should give true. Inside the aplication should be false, because this method use sessionId to check if sessionID is null or not. - Refresh Window. -> The value should give false inside the application during BackendServer initialization but it doesn't due to race-condition. When is it working - In network, we could uncheck "No throttling" and change this value to "Slow 3G" - Refresh window again. --> SessionID is set before and the conditional could execute the BackendServer code correctly. *See GIF attached. In that test, we are using the following logpoint. "IsLoginWindow ", !OB.App.View.isLoginWindow(),"IsLogginIn ", OB.App.Security.isLoggingIn() |
||
Revision | 2023-12-18 18:09 by ablasco | ||
Steps To Reproduce | How to check sessionTimeout Case: In Chrome Developer Tools. - Add a logpoint in registerAutomaticSessionTimeout() method and review Login SessionID inside of it. "IsLoginWindow ", OB.App.View.isLoginWindow() - In login window , this method should give true. Inside the aplication should be false, because this method use sessionId to check if sessionID is null or not. - Refresh Window. -> The value should give false inside the application during BackendServer initialization but it doesn't due to race-condition. When is it working - In network, we could uncheck "No throttling" and change this value to "Slow 3G" - Refresh window again. --> SessionID is set before and the conditional could execute the BackendServer code correctly. |
Copyright © 2000 - 2009 MantisBT Group |