Auth UI does not show if request to apiDomain is blocked

[nkshah2]

When using Stackblitz for:

• Frontend using React
• Backend using NodeJS

We observed that if the apiDomain configured in appInfo on the frontend had a port, the auth UI did not show up and no errors were logged to the console. Ideally even if the URL for apiDomain is invalid or the request fails, the UI should be rendered (even though logging in would not work). We need to verify that this is not an issue with the auth-react package (or any of its dependencies) and find out what was the cause (and if we can fix it for services like Stackblitz)

[nkshah2]

The issue can 100% be recreated when using StackBlitz but there are a few key things to note here

1. When using stackblitz and running an express server on a port, the port does not get appended to the domain but becomes part of the origin. For example if the node app on Stackblitz is assigned domain app.stackblitz.io and you use app.listen(8080), when you start the server the domain changes to app-8080.stackblitz.io. In the original issue there was an error and the new domain was not used which is why the network requests failed.

2. Stackblitz routes network requests to apps via their own servers, adjusting cors options for those requests is not an option and cors requests will always fail. This is a current limitation on the platform with multiple users complaining, for their use cases opting out of cors was an option but for ours it isnt.

Now lets consider an example where we are running the node server on api.stackblitz.io and the frontend on fe.stackblitz.io. When we first tested and found the issue we ran the server on 8080 and set the apiDomain to be api.stackblitz.io:8080. The problem is that that particular domain does not have an active app on it so when a network request is made it is neither accepted nor rejected and the browser simply waits for a response. Since we do not set a timeout on requests to the /refresh route the browser waits for the default timeout (3 minutes) before considering it a failed request. When the request is considered a failure the UI renders correctly.

Possible solutions:

• Add a network timeout to requests made by the package (This will require changes to the init config because the user should be allowed to change this timeout)

[rishabhpoddar]

Makes sense. We should add a network timeout. If a user wants to change this value, they can do so by using the pre API hook we provide. I think a good network timeout would be 10 seconds?

[rishabhpoddar]

Also, there are different types of timeout:

• Connection timeout (which we can keep really short ~3 seconds?)
• Response timeout (which we can keep 10 seconds)

I assume that the problem above would fall under connection timeout?

[Rituraj27]

The problem has arrived when i was unable to use the perfection of UI.. The UI is not soft anymore