Next.js: CORS error fetching external CSS on 9.5.3

Created on 12 Sep 2020  ·  26Comments  ·  Source: vercel/next.js

Bug report

Describe the bug

After upgrading to [email protected], the initial load of our page throws when requesting CSS from our CDN.

To Reproduce

  1. Create an app with a stylesheet, css or scss.
  2. Import that stylesheet into a component as a module.
  3. Build and upload your assets to a CDN using assetPrefix in next.config.js. Deploy your app and run in production mode.
  4. Notice that your initial page load throws with a CORS error.

Expected behavior

Preloading css should work cross domain or it should fail gracefully.

Screenshots

Developer Tools:
image

Elements View:
image

System information

  • OS: [e.g. macOS, Windows]
  • Browser: chrome
  • Version of Next.js: 9.5.3
  • Version of Node.js: 10

Additional context

I believe it's related to this PR:
https://github.com/vercel/next.js/pull/16581#issuecomment-691362392

story 3 needs investigation

Most helpful comment

I have the same issue.
Compiled file have a “registerPage” function,it use fetch to acquire external CSS.
ps: downgrading to v9.5.2 can fix the issue

All 26 comments

I have the same issue.
Compiled file have a “registerPage” function,it use fetch to acquire external CSS.
ps: downgrading to v9.5.2 can fix the issue

tagging @saponifi3d in case we get some response next week while I'm out.

have same issue, interesting why one chunk is preloaded using fetch, while we have preload link in html?
BTW if smbd like me needs quick fix - downgrading to v9.5.2 fixes issue.
as issue author states basically.

Hi :wave:

Same issue here too. Downgrading to v9.5.2.

Ive got this issue too, upgraded to webpack 5 and suspected it was something to do with crossOrigin loading, but it's the same cssRule issue mentioned here.

This is impacting PR environments that proxy through a stage URL with a query string or cookie value being placed to route assets from deploy locations (CDN) back to the PR env.

Downgrading to 9.5.2 is blocked for us by this CVE: https://nvd.nist.gov/vuln/detail/CVE-2020-15242

v9.5.2, v9.5.3 have a CVE out: https://nvd.nist.gov/vuln/detail/CVE-2020-15242
v9.5.4, 9.5.5 failed due this CORS error

We were forced to downgrade to v9.4.4 until this gets fixed...

We've had some success by discovering an undocumented prop that can be passed into <Head> in a custom document - make sure that it is the Head from next/document.

You can pass in the crossOrigin prop with a value of either anonymous or use-credentials (see relevant MDN). The fetch was successful 👍

edit: just found out that is deprecated - apparently you can add it in next.config.js instead - see relevant error

We've had some success by discovering an undocumented prop that can be passed into <Head> in a custom document - make sure that it is the Head from next/document.

You can pass in the crossOrigin prop with a value of either anonymous or use-credentials (see relevant MDN). The fetch was successful 👍

edit: just found out that is deprecated - apparently you can add it in next.config.js instead - see relevant error

thanks for the explanation @sophiekoonin . are you saying that by adding that config to my next.config.js all assets are loaded with CORS anonymous?

that's an interesting workaround!

@dkempner It seems that way - it's all the link and script tags that are added by Next (not any that you include manually). We're exporting our CSS + JS and hosting it on S3, so it works for us.

Thanks again for sharing @sophiekoonin. We confirmed that it works for us too.

Flipping this option on is potentially gonna block a few dozen services get to next 10.

Thrilled there's a workaround. Not all hero's wear capes 😂 thank youu

Started having issues with our Cloudfront deployment as well after upgrading. Some of the chunks get loaded dynamically and were failing due to missing CORS headers. Ended up doing the following:

  • we use a custom server set up with next, set up CORS headers correctly so all resources return Access-Control-Allow-Origin headers set
const express = require('express')
server.use(cors({
    origin: process.env.HOST,
    optionsSuccessStatus: 200 // some legacy browsers (IE11, various SmartTVs) choke on 204
}));
  • instruct Cloudfront to forward headers along (see this):
Access-Control-Request-Headers
Access-Control-Request-Method
Origin
Refer

This issue should be fixed in v10.0.1 https://github.com/vercel/next.js/releases/tag/v10.0.1 via #17930 / #18723

Thanks @bmathews I'll check it out!

Please let me know if https://github.com/vercel/next.js/pull/18723 fixed this bug for you! Otherwise, I'd love to fix this ASAP.

@Timer I've tried 10.0.1 and am still seeing the CORS error.

I've tried 10.0.1 and am still seeing the CORS error.

Me too.
image
An error occurs on this line.

It seems to be solved by specifying Access-Control-Allow-Origin header as * in CDN.

@dkempner can you confirm if this is fixed for you on 10.0.2-canary.10 or newer?

hey @Timer i can do that but it's gonna be a few days. i'll check back in within a week.

No problem! I setup a S3 bucket and confirmed Next.js worked correctly with an assetPrefix configured to be S3. Seems this is fully fixed in the latest Next.js canaries!

No problem! I setup a S3 bucket and confirmed Next.js worked correctly with an assetPrefix configured to be S3. Seems this is fully fixed in the latest Next.js canaries!

you're a king. thanks for that!

Just to clarify: CORS headers still need to be configured on the S3 bucket, but if you don't, Next.js will still allow pages to hydrate, but client side navigations will automatically fall back to a server transition until the CORS error is fixed.

Just to clarify: CORS headers still need to be configured on the S3 bucket, but if you don't, Next.js will still allow pages to hydrate, but client side navigations will automatically fall back to a server transition until the CORS error is fixed.

We've always had * as our CORS header for S3. Is that sufficient?

Should be!

Was this page helpful?
0 / 5 - 0 ratings