Fix: Creating new Loop pages after SharePoint domain change
Description
After a tenant changes their domain, this lead existing workspaces on the Loop app to stop allowing the creation of new pages. After a redirect, the authorization headers are not sent by the browser. And even if were to just retry with the headers set, SharePoint requires for the auth tokens to be generated for that particular domain.
After these changes, I was able to get new pages to attach again. What I did was catch the redirect on the fetchHelper( function, and allow getFileLink to handle the redirect for us. For this to work, we need to request new tokens for the new domain.
The fix is sadly not perfect as we need to go through the following flow in order to detect and retry the redirect error.
- The first call to getShareURL against the original URL gives us the 308
- The second one that gets made automatically by the browser to follow the 308 will be made against the new domain, but will fail due to tokens
- We need to catch that second one, and retry with new tokens. This call will succeed
Baseline CI build failed, cannot generate bundle analysis at this time
Baseline commit: 4c94050746966a2f1f6e6322b101fdb38b89f503
Generated by :no_entry_sign: dangerJS against bfd5f7534934a1006f1f617b1db32b5a3d40767f
@vladsud @pragya91 Can you guys please take a look at this PR? @jatgarg is not available right now and you both have the most context here.
Let's add a test for these new changes in getFileLink.spec.ts. You can mock throwing of the 403 error with redirected property in the response and see if the code works as expected.
@Philip-Scott As far as I remember the GetSharingInformation is not a blocking call for attach functionality to go through. However, this api is called when host tries to request the getAbsoluteUrl() on the resolver. Just wanted to highlight that, since the PR talks about the "unable to attach" issue.
Looks like this is now being handled with #21277