0

I am working on a project with some colleagues using ASP MVC 5 and we're using a lot of common Javascript libraries from public CDNs. I've configured and enabled CORS and everything works fine except with this one specific case and we're somewhat stumped at this point.

The app uses ASP.NET Identity 2 and some functions rely on the Impersonation feature. The backend implementation generally follows the answers here: How do I use ASP.NET Identity 2.0 to allow a user to impersonate another user?

The frontend uses an AJAX post with antiforgery tokens to a WebAPI endpoint (following this specific implementation: https://stackoverflow.com/a/24394578/5330050). To have the new identity take effect, the app does a window.location.reload(true);.

It is at this point that Firefox blocks all the CORS requests (all of which are requests for the libraries and frameworks hosted on CDNs). This is the specific error (same for all the requests, different lib, same domain):

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cdnjs.cloudflare.com/{some.js}. (Reason: CORS request did not succeed)

This issue only happens in Firefox. And it continues blocking these resources even if I attempt to navigate to a different page in the app. Unless I clear the cache (but not cookies so the identity still remains) then everything is fine again.

There's nothing special about how these resources are called. It's not a POST request. It's just up there in the <head>, for example:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>

Things that work to resolve it (but are unacceptable as far as user experience is concerned)

  1. Clear the cache (but not cookies)

  2. Wait 5 minutes (for Firefox to forget? Session is set to 12 hours on the server)

I don't really know what the cause could be and I appreciate any help in finding either a workaround or a clue as to where I could look for a solution.

Iskandar Reza
  • 953
  • 1
  • 7
  • 16
  • Have you tried another CDN? For example: `https://code.jquery.com/jquery-3.3.1.min.js`. Just to confirm that the issue is not related to `cdnjs.cloudflare.com`. – Matthijs Oct 13 '18 at 10:09
  • I just did a bunch of tests and am getting mixed results. `code.jquery.com` works but `stackpath.bootstrapcdn.com` gives me the same error at the same scenario. – Iskandar Reza Oct 13 '18 at 10:39
  • What if you remove the `integrity` and `crossorigin`? And what happens if you regenerate this? – Matthijs Oct 13 '18 at 10:52
  • I removed those tags and I'm still getting the error. Can you clarify what you mean by regenerate this? – Iskandar Reza Oct 13 '18 at 11:08
  • You can regenerate the integrity and crossorigin with: https://www.srihash.org/. I don't think it will resolve the issue, but just to be sure this doesn't cause the problem. I'd suggest to use the `code.jquery.com` CDN or similar as a workaround (for now) – Matthijs Oct 13 '18 at 11:09

1 Answers1

0

This is not really an answer, but I have found out specifically what is going on with my case above. I have a follow up question but before that I will share what I found:

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Requests_with_credentials

When responding to a credentialed request, the server must specify an origin in the value of the Access-Control-Allow-Origin header, instead of specifying the "*" wildcard.

Because the request headers in the above example include a Cookie header, the request would fail if the value of the Access-Control-Allow-Origin header were "*". But it does not fail: Because the value of the Access-Control-Allow-Origin header is "http://foo.example" (an actual origin) rather than the "*" wildcard, the credential-cognizant content is returned to the invoking web content.

Note that the Set-Cookie response header in the example above also sets a further cookie. In case of failure, an exception—depending on the API used—is raised.

This is exactly what is going on because this issue does not occur until the user is logged in. cdnjs (or whatever other CDN out there) would send the wildcard header because that's the standard for how it's done.

I'm still confused why it's happening with a script tag though so my follow-up question would be along those lines.

Iskandar Reza
  • 953
  • 1
  • 7
  • 16