Chore/2.0.0

[Baroshem]

Types of changes

• Bug fix (a non-breaking change which fixes an issue)
• New feature (a non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

#475
#488
#485
#496
#494
#501
#497
#514

Description

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes (if not applicable, please state why)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
nuxt-security	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 19, 2024 11:01am

[Baroshem]

@vejja if you agree, I would love to merge this PR and release a brand new 2.0.0 version :)

[vejja]

I think this section should not be removed
The vite nonce is only inserted in dev mode, if I understand correctly
@dargmuesli is this true?

[dargmuesli]

I think all offending actions are only executed in dev mode as well. Styles should not be added through JavaScript by Nuxt in production as far as I know. They're just referenced as compiled CSS content in production, at least without changes to any configuration.
I have the fix contained in this PR running for a few of my sites for quite some time now and have not observed any issues (even with close monitoring done by Sentry).

Maybe @danielroe could quickly confirm or refute that style loading through JavaScript only happens in dev mode by vite and, by default, not by Nuxt in production?

[vejja]

I'm pretty sure we had to use unsafe-inline in styles in our own doc website, because @nuxt/ui uses pinceau under the hood, and pinceau modifies styles dynamically at runtime via Javascript.

[dargmuesli]

Ok, but that's somewhat 3rd party, no? The section talks about "Nuxt's mechanism for Client-Side hydration of styles" so maybe the wording should be changed then to reflect the actual reason for the recommendation better. I'd still say the recommendation doesn't really need to be that prominent for the pinceau use case though, but that's just an opinion.

[dargmuesli]

I'll unsubscribe from this PR to reduce noise, just tag me again if you need me

[vejja]

I've got 2 general comments on this PR:
1- Let's check whether unbuild manages to find the local imports. I think I remember we need to add them manually to package.json
2- The regex serializer/deserializer is quite complex. Unless @Baroshem is comfortable with the logic, I would love to see comments and test examples added, so that we understand better the rationale

[vejja]

Hey @P4sca1
Isn’t it a bit severe ?
You could probably use ‘unsafe-hashes’ here, and the inline code is always the same so you could pre-hash it.
I do agree this is not ideal though. @harlan-zw was able to replace all inline event handlers with addEventListener in @nuxt/scripts so maybe the team at NuxtImg can use the same approach?

[P4sca1]

The inline code will indeed be always the same, so using unsafe-hashes could work. Maybe we could add it by default in non strict mode or behind a feature flag in strict mode to support <NuxtImg> and <NuxtPicture>.

I calculated the hash that would be needed:

echo -n "this.setAttribute('data-error', 1)" | openssl sha256 -binary | openssl base64
bwK6T5wZVTANitXbrTsel7kl/PyCjCd/Dq5Qoz3imjM=

Using addEventListener in this case is not trivial, because the event listener would be attached in onMounted(), which is too late for some kind of errors. So some errors, e.g. when the url is invalid, could be missed.

[vejja]

Hey @P4sca1
What is the issue when CSP denies execution of the error handler?

[P4sca1]

The data-error property does not get set on the image tag and the error event is never emitted.
From a user's perspective the page works fine, it just shows an unloaded image.

[Baroshem]

Hey @Shana-AE could you work on the improvements suggested by @vejja ? :)

[vejja]

@Baroshem just a general comment here on providing a regex serializer/deserializer
The official Nuxt docs say that we should not do this:

On balance though, the CORS handler is a native h3 feature, which is supposed to allow Regexes.
I am a bit puzzled at whether regexes are allowed/not allowed in nuxt.config.ts.

[Baroshem]

Hmm, at this point maybe it would be safer to revert this change and plan it for 2.1.0? What would be your recommendation Sebastien? :)

[vejja]

Hmm, at this point maybe it would be safer to revert this change and plan it for 2.1.0? What would be your recommendation Sebastien? :)

Yes, agree with this Jakub.
We would have more time to check with @danielroe on why regexes are not allowed in nuxt.config.ts but allowed in h3 - how they recommend we deal with this

[Shana-AE]

@Baroshem just a general comment here on providing a regex serializer/deserializer The official Nuxt docs say that we should not do this:

On balance though, the CORS handler is a native h3 feature, which is supposed to allow Regexes. I am a bit puzzled at whether regexes are allowed/not allowed in nuxt.config.ts.

Thanks for pointing out the documentary :)
I just found that regexp didn't work, and after debugging, I found regexp was serialized to {}. and this is because that runtimeConfig was merged with env and serialized with JSON.stringify() before it was passed to h3. as I mentioned in #497.
I only got the runtimeConfig came from nitropack and got the value from process.env.RUNTIME_CONFIG. I'm just a new user of nuxt, so I didn't know more things about the detail that Why runtimeConfig was serialized and deserialized
I know the problem, and I know the superficial reason, but don't know about the deeper reason, so I just made "it works" through make Regexp can be serialized and restored, though ugly.
I think maybe we should use other things than runtimeConfig to store the config ? or if there is a best practice to make regexp serializable?

[Shana-AE]

Hey @Shana-AE could you work on the improvements suggested by @vejja ? :)

About the test and document, I want to know if there's a better solution to solve this problem. #497 it maybe or should be replaced with a better solution
And I want to know if there is a guide about writing test or coverage report?

[vejja]

@Baroshem just a general comment here on providing a regex serializer/deserializer The official Nuxt docs say that we should not do this:
On balance though, the CORS handler is a native h3 feature, which is supposed to allow Regexes. I am a bit puzzled at whether regexes are allowed/not allowed in nuxt.config.ts.

Thanks for pointing out the documentary :) I just found that regexp didn't work, and after debugging, I found regexp was serialized to {}. and this is because that runtimeConfig was merged with env and serialized with JSON.stringify() before it was passed to h3. as I mentioned in #497. I only got the runtimeConfig came from nitropack and got the value from process.env.RUNTIME_CONFIG. I'm just a new user of nuxt, so I didn't know more things about the detail that Why runtimeConfig was serialized and deserialized I know the problem, and I know the superficial reason, but don't know about the deeper reason, so I just made "it works" through make Regexp can be serialized and restored, though ugly. I think maybe we should use other things than runtimeConfig to store the config ? or if there is a best practice to make regexp serializable?

Understood @Shana-AE, thanks for the explanation
I don’t know the exact answer, but we will find out

[P4sca1]

Here is my attempt on fixing the RegExp issue: #509
Would love to hear your feedback. I noticed that we do not have any CORS test fixture yet. Would be great to add some tests in the future.

UPDATE: I also added a new test fixture for CORS with my PR.