I have restructured our usage of the react-msal package used for authenticating with Microsoft Entra ID to be more like the official examples. The most significant change is that msal's PublicClientApplication object is created and initialized inside of src/index.tsx,which is also where ReactDOM.render() is called. Besides (hopefully) fixing a known and irksome bug as detailed below, this makes the control flow of our auth system easier to understand and work with.
Now that ReactDOM.render is not called until after the PublicClientApplication is finished initializing, no API calls are made before it has been fully initialized. My hope is that this will fix the issue where multiple API calls triggered a redirect when requesting a token. In theory, the token should be able without redirecting once the first redirection has finished. However, I suspect that because the API calls were requesting a token before the PublicClientApplication had finished initializing, the token was not yet available and so each API call triggered another redirection.
Unfortunately, this behavior is extremely difficult to test because it only occurs when the refreshToken has expired, which takes at least 4 hours after a successful redirection. When I ran it this morning, it seemed to have resolved the redirect issue. More testing by more users in Train will be valuable for checking whether that's really true.
I have restructured our usage of the
react-msalpackage used for authenticating with Microsoft Entra ID to be more like the official examples. The most significant change is that msal'sPublicClientApplicationobject is created and initialized inside ofsrc/index.tsx,which is also where ReactDOM.render() is called. Besides (hopefully) fixing a known and irksome bug as detailed below, this makes the control flow of our auth system easier to understand and work with.Now that
ReactDOM.renderis not called until after thePublicClientApplicationis finished initializing, no API calls are made before it has been fully initialized. My hope is that this will fix the issue where multiple API calls triggered a redirect when requesting a token. In theory, the token should be able without redirecting once the first redirection has finished. However, I suspect that because the API calls were requesting a token before thePublicClientApplicationhad finished initializing, the token was not yet available and so each API call triggered another redirection.Unfortunately, this behavior is extremely difficult to test because it only occurs when the
refreshTokenhas expired, which takes at least 4 hours after a successful redirection. When I ran it this morning, it seemed to have resolved the redirect issue. More testing by more users in Train will be valuable for checking whether that's really true.