LoginCallback component not working after deploying application to test server

I have build a VueJs application implementing the SPA authentication work flow. The application works fine on my local machine, I am able to authenticate and everything works as expected. After deploying the application to a test server running Windows server 2016 IIS the redirect call back fails. I am able to get to the Okta login but when the redirect call back hits my router there is an error in the
LoginCallback component. All I see is a blank screen with the following error.

Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of “text/html”. Strict MIME type checking is enforced for module scripts per HTML spec

The error only happens when IIS is running the application, in VSCode it works fine. Any tips on trouble shooting or ways to solve this would be appreciated.

These articles seem to indicate that the error can occur if the app is deployed to a subfolder instead of the root. Can you confirm if you’re doing something similar?

I have seen similar articles, so in order to test this idea I have created the app in a few different setups. I created a brand new website running under localhost:85 with my application located in the root directory. I have also setup it up as a new application running under the default website in which is was a subfolder. My experience so far has been the same, I get the same blank page with the same MIME type error. Thank you for the articles, I will go through them to see if there is something new I can try.

I noticed that the request url being called is to
http://localhost:85/login/assets/index-0c58c523.js. There is no login folder, the path should be
http://localhost:85/assets/index-0c58c523.js but it appears this is being set by the LoginCallback component.

I found a temporary solution, if I add a copy of assets folder under [main directory]/login then the application works correctly. From what I can gather the LoginCallback simply calls await this.$auth.handleLoginRedirect(); during the beforeMount hook. this is removing the /callback part of the uri but leaving the login part which was breaking my routes. By adding the login directory and putting a copy of assets folder in it. Allowed the application to work, because logging in was the only thing not working.

If someone knows of a way I can fix this without having a duplicate assets folder I would appreciate the info.


Typically when serving a SPA from a web/app server where the callback URL is not a actual route on web/app server you need to add URL re-write rules.

The below is from Angular docs, but shows some common app server solutions to setup re-write rules.

Hope that helps


Thank you for your response. Yes, I know and I have those rules in place. I was following all the recommendations I found on the forums which allowed me to get to the point of having a blank screen after the login/call back.

When running in VSCode I can see the network traffic hitting my @vite client to route the redirect. In my IIS application I saw it was appending /login to the expected url. So instead of going back to the root of the application of index.html it was going to /login/index.html. Which is why I create the sub directory of login added the assets folder there and my application began working. I don’t like this for a final solution to the problem, is there something in $auth.handleLoginRedirect() that could either be only taking off the callback portion of the redirectUri so the /login portion stays or something else?