0054156: Race-Condition - Deferred Login State Initialization During the Login Process

Anonymous | Login

Project:

News | My View | View Issues | Roadmap | Summary

View Revisions: Issue #54156		[ 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.

Revision	2023-12-18 18:09 by ablasco
Description	Sometimes, the Login state requires the definition of the sessionID variable to verify whether we are inside or outside the application. During the Login load ( or refresh ), various processes (such as loading Masterdata, backendserver initialization, among others) can be executed in parallel, and the definition of sessionID is a resource that may not be defined in some cases. There are certain processes dependent on sessionID to identify that they are running within the application. (For example, the Backend Server initializes various Timeouts, such as the LogoutSession Dialog.) If the system is overloaded with other processes, most of the time it will work, establishing the sessionID variable. However, if the system is fast and lightweight ( not so common ), it may happen that the session variable resource is not defined for a condition, creating a conflict that may fail to initialize some background processes. Therefore, there is a possibility that some functionalities might not work due to a race-condition, and in cases where they do work, it is due to the overload of processes. This can be verified by slowing down the 3G throttle from Chrome Developer Tools. There may be times when the session variable is well defined during the Login process, but it should also be considered that refreshing the page can reinitialize the sessionID variable and cause a conflict.

Revision	2023-12-18 18:08 by ablasco
Description	Sometimes, the Login state requires the definition of the sessionID variable to verify whether we are inside or outside the application. During the Login load ( or refresh ), various processes (such as loading Masterdata, backendserver initializion, among others) can be executed in parallel, and the definition of sessionID is a resource that may not be defined in some cases. There are certain processes dependent on sessionID to identify that they are running within the application. (For example, the Backend Server initializes various Timeouts, such as the LogoutSession Dialog.) If the system is overloaded with other processes, most of the time it will work, establishing the sessionID variable. However, if the system is fast and lightweight ( not so common ), it may happen that the session variable resource is not defined for a condition, creating a conflict that may fail to initialize some background processes. Therefore, there is a possibility that some functionalities might not work due to a race-condition, and in cases where they do work, it is due to the overload of processes. This can be verified by slowing down the 3G throttle from Chrome Developer Tools. There may be times when the session variable is well defined during the Login process, but it should also be considered that refreshing the page can reinitialize the sessionID variable and cause a conflict.