Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chore/2.0.0 #492

Open
wants to merge 21 commits into
base: main
Choose a base branch
from
Open

Chore/2.0.0 #492

wants to merge 21 commits into from

Conversation

Baroshem
Copy link
Owner

@Baroshem Baroshem commented Jul 16, 2024

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

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)

Copy link

vercel bot commented Jul 16, 2024

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 Aug 9, 2024 11:53am

feat-#487: local dev with nuxt devtools
feat(doc): introduce Nuxt Scripts as alternative to `useScript`
@Baroshem
Copy link
Owner Author

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

@@ -215,15 +215,6 @@ export default defineNuxtConfig({
- `"'nonce-{{nonce}}'"` placeholder: Include this value in any individual policy that you want to be governed by nonce.


::alert{type="warning"}
Copy link
Collaborator

@vejja vejja Jul 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

@vejja vejja Jul 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@dargmuesli dargmuesli Aug 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

@vejja vejja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

src/module.ts Outdated Show resolved Hide resolved
src/runtime/nitro/plugins/00-routeRules.ts Outdated Show resolved Hide resolved
src/utils/originRegExpSerde.ts Outdated Show resolved Hide resolved
vejja and others added 3 commits August 2, 2024 20:18
Signed-off-by: Pascal Sthamer <10992664+P4sca1@users.noreply.github.com>
Signed-off-by: Pascal Sthamer <10992664+P4sca1@users.noreply.github.com>
</script>
```
When using `<NuxtImg>` or `<NuxtPicture>`, an inline script will be used for error handling during SSR.
This will lead to CSP issues if `unsafe-inline` is not allowed and the image fails to load.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Owner Author

Baroshem commented Aug 9, 2024

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

@vejja
Copy link
Collaborator

vejja commented Aug 9, 2024

@Baroshem just a general comment here on providing a regex serializer/deserializer
The official Nuxt docs say that we should not do this:
Screenshot 2024-08-09 at 12 22 21

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
Copy link
Owner Author

Baroshem commented Aug 9, 2024

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
Copy link
Collaborator

vejja commented Aug 9, 2024

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
Copy link

Shana-AE commented Aug 9, 2024

@Baroshem just a general comment here on providing a regex serializer/deserializer The official Nuxt docs say that we should not do this: Screenshot 2024-08-09 at 12 22 21

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
Copy link

Shana-AE commented Aug 9, 2024

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
Copy link
Collaborator

vejja commented Aug 9, 2024

@Baroshem just a general comment here on providing a regex serializer/deserializer The official Nuxt docs say that we should not do this: Screenshot 2024-08-09 at 12 22 21
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
Copy link

P4sca1 commented Aug 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve local development with NuxtDevtools
5 participants