In our current app implementation, after a successful login using the launchpad login page, users were experiencing an unintended behavior when attempting to navigate back using the browser's back button. This issue arose because, initially, we were using "window.location.href" to redirect users to the login page, which then resulted in the login page URL being stored in the browser's history.
To address this issue, we have switched to using "window.location.replace" upon successful login. This method replaces the current URL in the browser's history with the app's URL, ensuring that the login page URL is not stored in the history. As a result, when users hit the browser's back button, they are not redirected to the login page again.
We considered an alternative approach of blocking access to the login page if a user is already authenticated. However, this approach was not feasible due to the presence of a query parameter, "isLoggedOut," in the login page URL when the user first accesses the launchpad login. This parameter is initially set to true and, upon successful login, gets stored in the browser history. Consequently, hitting the back button would cause the user to be redirected to the login page with the "isLoggedOut" query parameter set to true, falsely indicating that the user is logged out.
Given these considerations, we have opted to continue with the first approach of using "window.location.replace" to manage the navigation behavior after a successful login and to ensure a smoother user experience.
Screenshots of Visual Changes before/after (If There Are Any)
IMPORTANT NOTICE - Remember to add changelog entry
Contribution and Currently Important Rules Acceptance
Related Issues
Closes #51
Short Description and Why It's Useful
In our current app implementation, after a successful login using the launchpad login page, users were experiencing an unintended behavior when attempting to navigate back using the browser's back button. This issue arose because, initially, we were using "window.location.href" to redirect users to the login page, which then resulted in the login page URL being stored in the browser's history.
To address this issue, we have switched to using "window.location.replace" upon successful login. This method replaces the current URL in the browser's history with the app's URL, ensuring that the login page URL is not stored in the history. As a result, when users hit the browser's back button, they are not redirected to the login page again.
We considered an alternative approach of blocking access to the login page if a user is already authenticated. However, this approach was not feasible due to the presence of a query parameter, "isLoggedOut," in the login page URL when the user first accesses the launchpad login. This parameter is initially set to true and, upon successful login, gets stored in the browser history. Consequently, hitting the back button would cause the user to be redirected to the login page with the "isLoggedOut" query parameter set to true, falsely indicating that the user is logged out.
Given these considerations, we have opted to continue with the first approach of using "window.location.replace" to manage the navigation behavior after a successful login and to ensure a smoother user experience.
Screenshots of Visual Changes before/after (If There Are Any)
IMPORTANT NOTICE - Remember to add changelog entry
Contribution and Currently Important Rules Acceptance