Cross-origin redirection denied by CORS policy: Cancelled load because it violates the resource's CORS response header

Get Help
,
1

Greetings,

I am trying to implement cross-origin isolation for my web app, and am running into a quagmire in the process. I’ve set the headers in my VirtualHost in Apache properly, and have confirmed that cross-origin isolation is running. However, this has caused a conflict with my Auth0 implementation - specifically, I’ve started getting the message in the Subject of this topic.

I deduced that the probably cause was that I was changing domain from my app’s domain to my Auth0 domain (“dev-…”). I therefore set up a custom domain which matched my app’s domain name. Once this was in place, I tested and found that I got the same error, with the custom domain in place of the original Auth0 domain.

My suspicion is that I forgot to configure something (or things), but I’m not sure what. Please advise.

Thanks!

Addendum: Refreshing the page continues execution and brings up the Universal Login correctly.

3

Hi @david42

I am sorry about the delayed response to your inquiry regarding the matter!

Are you using loginWithPopup by any chance in your application? If you are, I believe the issue might be caused due to the strict same origin CORS policy which might sever the communication link on which the Auth0’s loginWithPopup relies on when enabling CO Isolation. In this situation, using a custom domain will not fix the issue because even if the both domains would be Same Site but not Same Origin.

I would recommend to change your configuration in order to use same-origin-allow-popups instead of same-origin OR to use loginWithRedirect instead if possible.

If you have any other questions or still experience issues with this, let me know!

Kind Regards,
Nik

4

Hi Nik,

Well, no. I’m not usingloginWithPopup,at least not explicitly.

However, an additional detail is worth mentioning - I found that if after I got the error message I refreshed the page, execution continues and I get the proper Auth0 login dialog, as if nothing was wrong.

The net effect is that this error doesn’t freeze further development, but is an unacceptable problem in production which needs to be addressed.

Any thoughts?

David

5

Got it!

Do you use any kind of wildcard entries for domains in your CORS configuration as such:

Access-Control-Allow-Origin: *

If you do, could you please try changing the values to something specific to see if it impacts the behaviour in any way? Also, for the Access-Control-Allow-Credentials header, did you set it to true or false?

Also, do you check or handle the login using resources which resolve during an iframe such as checkSession which would lack the initial isolation headers which would then properly be sent after a refresh?

Kind Regards,
Nik

6

Hi Nik,

I have the following headers in my configuration related to CORS:

Cross-Origin-Opener-Policy "same-origin"
Cross-Origin-Embedder-Policy "require-corp"

Neither.

No.

David

7

Hi Nik,

So, after some research, I think I found the issue, but I’m also between a rock and a hard place…

On the one hand, I need the headers I mentioned above in order to implement cross-origin isolation for this site. On the other hand, same-origin requires that everything resolves to “www.fotlr.org” (my site name) while my custom domain is “login.fotlr.org”, which isn’t a match. Furthermore, unless I’m mistaken, I can’t have a custom domain “www.fotlr.org” because the CNAME would conflict with the site’s name. Or would it?

Thanks,

David

8

Thanks for the extra information @david42

After some research, as you have mentioned, you will not be able to use a custom domain for www.forlt.org on Auth0 since you would be required to use a subdomain (such as login or auth).

I believe you should be able to resolve the issue while still keeping CO Isolation by having SharedArrayBuffer enabled, making sure you initialize any login calls with loginWithRedirect and enabling Refresh Tokens while using the local storage.

The standard silent authentication would be using an iFrame which can be blocked by your require-corp header. If you are initializing your login call with loginWithRedirect and you have already configured the things mentioned above, please let me know what kind of application you are using for your CO Isolation and how you have configured your Auth0 SDK within the application.

Kind Regards,
Nik

9

Hi Nik,

Hmm… The objective, obviously, is to enable SharedArrayBuffer. The specific reason is that the site in question involves an embedded Zoom Client, and enabling SharedArrayBufferhelps the Zoom Client function properly.

If there is another way to enable this, without the CORS conflict, I’d like to know how. I’m afraid the rest of your suggestions read foreign to me, so any references or walkthroughs would be greatly appreciated.

David

10

Got it, I will be looking further into that.

Could you please let me know what kind of SDK are you using in order to provide accurate information on the implementation?

Kind Regards,
Nik

11

Hi Nik,

I’m not sure whether you’re asking about the Zoom SDK or the Auth0 SDK… For Zoom, I’m currently using their Meeting SDK for Web, which involves some JavaScript..

The Auth0 implementation is from the NuGet package “Auth0.AspNetCore.Authentication” v.1.5.1.

David

12

Hi again!

Since you are using AspNetCore authentication, you can initialize the service to use Refresh Tokens like this:

public void ConfigureServices(IServiceCollection services)
{
    services
        .AddAuth0WebAppAuthentication(options =>
        {
            options.Domain = Configuration["Auth0:Domain"];
            options.ClientId = Configuration["Auth0:ClientId"];
            options.ClientSecret = Configuration["Auth0:ClientSecret"];
        })
        .WithAccessToken(options =>
        {
            options.Audience = Configuration["Auth0:Audience"];
            options.UseRefreshTokens = true;
        });
}

You will also need to enable offline access for your API by going to the Auth0 Dashboard → Applications → APIs → Allow Offline Access. Once this is enabled, you application will need to pass int he additional offline_access scope during authentication.

Could you provide me a sample of how are you handling the login and redirection inside the application which is triggering the CORS error so I can take a better look and understand the implementation?

Let me know if that helps with the CORS issue or not.

Kind Regards,
Nik