App suddenly crash when using flask-dance with AZURE AD (CORS policy problem)

Hello guys,

I have built a new WEB APP in Dash that authenticate the users using AZURE AD SSO:

And I did note that after some time idle, the app stop to work but it doesn’t raise any error, only showing the message that show the info that the server is unavailable…


I did note that in the browser console, it is showing the following warning/error:


Error description

Access to fetch at ** < LINK > **** (redirected from ‘http://localhost:8050/_reload-hash’) from origin ‘http://localhost:8050’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

I would like to know if someone has faced this problem before or if someone knows how to deal with it... I did some searches and tried some approaches but I do not have any idea on how to solve the problem.

Any help on how to debug it will be really appreciated.



Hello @kabure,

Did you try adding "mode": "no-cors" header to the fetch in api.js?

1 Like

Hello Bryan,

Thank you for your answer mate… Do you have any idea how could I do it?

As I’m using flask-dance to deal with the auth process, I think that the fetch in api.js is made behind the scenes;

Hey @jinnyzor

I found a snippet code that I have adapted with your suggestion… I’m not sure if it will work, but if it works or not I will update this thread with the answer


Hmmm, I dont know if that is a great way to go about it…

It is interesting that localhost doesnt work for the requests.

Did you come up with a good solution? I believe that the proposed approach of disabling CORS poses a significant security concern.

Looking at this again, it seems as if it might be an issue with the redirect.

Is it possible to handle the refreshing of the token on the server side instead of on the client?

This could also be an issue with the registry of the application on the azure side as well. The urls I think should be updated for where they will redirect to, not a localhost, but the full hosted web address?