feat: allow configuring headers in runtime #298

huang-julien · 2023-11-19T14:21:01Z

resolve #258

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)

Description

Hi 👋

This PR allows to configure headers configuration in runtime.

users will simply have to call nuxt-security:headers hook to change the configuration. The new configuration will have a higher priority than the routeRules .

Strangely, auto scanned plugins have a higher priority than registered plugins. So I also created the nuxt-security:ready nitro hook.

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 · 2023-11-19T14:21:06Z

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	Jan 10, 2024 8:58pm

huang-julien · 2023-11-19T14:29:30Z

@dargmuesli @Baroshem @harlan-zw Would love to have your feedback !

@pi0 feel free to correct this PR 😅 , i really hope this looks good to you

dargmuesli

Looks good at the first glance! I will try it out later ❤️

Baroshem · 2023-11-20T05:00:03Z

Hey, amazing work!

Would you be ok if we could merge it to the 1.1.0 version that I am planning to release in December?

This week, I would love to release 1.0.0 and your change would work perfectly for the first minor update after stable 1.0.0 :)

huang-julien · 2023-11-20T08:26:38Z

Sure ! I guess we can also iterate on 00-context to allow more configurable options in the future but users are mostly asking for configurable CSP (including myself) for now

src/types/index.ts

harlan-zw · 2023-11-21T04:38:40Z

src/types/index.ts

+
+declare module 'nitropack' {
+  interface NitroRuntimeHooks {
+    'nuxt-security:headers': (route: string, headers: SecurityHeaders) => void


I haven't dug into how the module works but this type of augmentation generally doesn't work when users install the module.

You need to use the runtime-generated types for this sort of thing usually.

Also I'd type it as Promise<void> | void so users can use promises.

Personally I'd use a single context object instead of two separate params and I'd use a H3Event over the route.

Not required though

yes, we probably need to add a reference in a d.ts file. I'll verify if this works later !

would you prefer something like this?

'nuxt-security:headers': ({ route: string, headers: SecurityHeaders }) => void

yes, it just makes it easier if you want to add other things into the hook context later

// if it makes sense 'nuxt-security:headers': ({ event: H3Event, headers: SecurityHeaders }) => void | Promise<void>

harlan-zw · 2023-11-21T04:42:08Z

src/runtime/nitro/plugins/00-context.ts

+    })
+
+    nitroApp.hooks.hook('request', (event) => {
+        event.context.security = event.context.security || {}


I'd use the module name to avoid conflicts

i used security because it's the module configKey, but yeah we can change it to nuxtSecurity !

I think if ends users will use this context object it could make sense with this name, otherwise if it's just internal module name is better.

I would stick to security instead of nuxt-security purely because this is a config key for both nuxt.config.ts file and for route rules so it would be better IMHO to keep this consistent :)

harlan-zw · 2023-11-21T04:43:22Z

src/runtime/nitro/plugins/00-context.ts

+export default defineNitroPlugin((nitroApp) => {
+    const router = createRouter()
+
+    nitroApp.hooks.hook('nuxt-security:headers', (route, headersConfig) => {


I have a feeling this would be better suited if it was called on each request, otherwise, the user should just use route rules?

Do you mean it would be up to us to call a hook insteading of hooking into the event ?

I also thought of this. The reason I made nuxt-security hooking into it instead of calling the hook is because we would need to await all hooks.

So if users are doing a long async hooks, this would block their response

I don't think routeRules are editable is it ? If not, there's another way to do runtime configuration. It is to have a security/nuxtSecurity property from event.context and to change the headers based on its value in a middleware

I need to dig into the code a bit deeper to answer this, think I'm missing some context. Will get back to you when I have a chance (otherwise feel free to ping me)

👍 feel free to ping/call me, maybe can we try to find a better implementation together with @dargmuesli and @Baroshem

src/types/index.ts

Baroshem · 2023-12-27T12:59:58Z

@huang-julien

Sorry for waiting so much for my feedback on this great PR. I am back again and could take a look at it .

Do you need me to answer any particular discussion?

Baroshem

Few questions/suggestions

src/runtime/server/middleware/headers.ts

docs/content/1.documentation/2.headers/15.runtimeConfiguration.md

Baroshem · 2023-12-27T13:08:31Z

playground/nuxt.config.ts

@@ -24,6 +24,7 @@ export default defineNuxtConfig({
    rateLimiter: {
      tokensPerInterval: 10,
      interval: 10000
-    }
+    },
+    runtimeHooks: true


question: I wonder if this should actually be enabled by default. I think that majority of the users will just use the nuxt.config.ts config or route rules while this runtime configuration is a bit of an edge case (at least IMO).

With these kind of configuration, I usually mark them as optional and disabled by default (to not ship unused code to other users).

So, if you want to have a runtime configuration, just set this config value security.runtimeHooks = false and it will work for you.

WDYT?

oh i didn't remove this since the removal of the runtimeHooks option

@harlan-zw think we don't really need this option to always have a runtime configuration of headers. So should we set back runtimeHooks in the options ?

If we set back runtimeHooks option, i think it should be default to false. Then if true, we'll add the nitro plugin

I personally would recommend to add an option and make it disabled by default to not add additional code for users that may not use it.

So add an option but make it disabled by default and make a note in the docs that in order to use this feature, set this config option to true and then, call the hook (like you have explained in the docs)

I think this delivers the functionality to the user that may need it without forcing every user of the module to have some dead code.

harlan-zw · 2023-12-28T10:21:50Z

Having reviewed the source and looking at this PR again, I think the best solution would be to introduce a composable to resolve the security route rules.

Currently, each function is doing this:

// nuxt-security plugin
const { security } = getRouteRules(event)

The PR to my understanding is solving the issue of users wanting to modify this security var at runtime. In theory, a user could just modify the route rules within a nitro plugin event.context._nitro.routeRules, but the DX isn't great.

Instead, using a new composable that wraps this logic while also exposing a Nitro hook should solve the issue.

export async function resolveSecurityContext(e: H3Event) {
  const routeRules = getRouteRules(event).security
  const nitroApp = useNitroApp()
  const context = { rules: { ...routeRules } } // can't remember if this is frozen, you may need to do a clone (see klona)
  await nitroApp.hooks.hook('nuxt-security:context', context)
  return context
}

// nuxt-security plugin
const security = await resolveSecurityContext(event)

The only catch is that you don't want users running slow events in this hook. So I'd update the docs with an example like so.

export default defineNitroPlugin((nitroApp) => {
  const myCustomSecurityRules = await $fetch('/security')
  nitroApp.hooks.hook('nuxt-security:context', (context) => {
      context.rules = defu(context.rules, myCustomSecurityRules)
  })
})

Let me know what you think of this and if it solves the issue. Also feel free to name the composable / hook to whatever you think makes the most sense.

Baroshem · 2024-01-10T12:10:31Z

@huang-julien any update from your side? I would love to plan 1.1.0 release with this feature :)

huang-julien · 2024-01-10T13:12:53Z

Yup probably this weekend, i didn't had a lot of time since the end of holidays 😭

huang-julien · 2024-01-10T21:03:42Z

docs moved to usage following @Baroshem's suggestion
lint
set back runtimeHooks option following @Baroshem's suggestion
fix: added type augmentation
transformed the hook parameters into a context object following @harlan-zw 's suggestion

Having reviewed the source and looking at this PR again, I think the best solution would be to introduce a composable to resolve the security route rules.

Currently, each function is doing this:
// nuxt-security plugin
const { security } = getRouteRules(event)
The PR to my understanding is solving the issue of users wanting to modify this security var at runtime. In theory, a user could just modify the route rules within a nitro plugin event.context._nitro.routeRules, but the DX isn't great.

Instead, using a new composable that wraps this logic while also exposing a Nitro hook should solve the issue.
export async function resolveSecurityContext(e: H3Event) {
  const routeRules = getRouteRules(event).security
  const nitroApp = useNitroApp()
  const context = { rules: { ...routeRules } } // can't remember if this is frozen, you may need to do a clone (see klona)
  await nitroApp.hooks.hook('nuxt-security:context', context)
  return context
}
// nuxt-security plugin
const security = await resolveSecurityContext(event)
The only catch is that you don't want users running slow events in this hook. So I'd update the docs with an example like so.
export default defineNitroPlugin((nitroApp) => {
  const myCustomSecurityRules = await $fetch('/security')
  nitroApp.hooks.hook('nuxt-security:context', (context) => {
      context.rules = defu(context.rules, myCustomSecurityRules)
  })
})
Let me know what you think of this and if it solves the issue. Also feel free to name the composable / hook to whatever you think makes the most sense.

I think this can probably have it's own PR. I completly agree that having a composable will be better in terms of DX 👍 . The only issue i see is the hook being possibly async which can block the request, that's why it's up to the user to call the hook instead the other way in this PR.
What do you think @harlan-zw ?

Please tell me if anything needs a change or if I forgot anything :)

harlan-zw · 2024-01-15T14:23:35Z

Separate PR is good with me, whatever is easy. It shouldn't be an issue as long as long as it's clear to the user that should be covered by the docs (explicit code example of what's good practice) and the fact that all server hooks are async and block the request.

If you just want to get this PR over the line then please ignore my input and go ahead with what you have as it still solves the issue

vejja · 2024-01-16T22:33:44Z

Hi @huang-julien
I'd like to consider introducing a deeper refactoring of our Nitro plugins that would be based on your approach.
Your PR seems to provide a proper foundation for solving other issues, e.g. #335 which is fundamentally caused by us trying to resolve headers in various parts of the module.
Would you mind if we discuss this in another thread ?

Baroshem · 2024-01-17T06:41:02Z

Looks good from my side now :)

huang-julien · 2024-01-17T08:12:37Z

Hi @vejja 👋
Sure we can :)

vejja · 2024-01-17T10:15:25Z

Hi @vejja 👋 Sure we can :)

Thanks !
Let's move it to #346
I am basically trying to lay out my understanding of how it works, would be extremely happy to have your feedback - especially on the assumptions I'm making about your PR

Baroshem · 2024-01-18T09:34:42Z

@huang-julien @harlan-zw @vejja @dargmuesli

I am merging this PR and will release it as 1.1.0. Thanks for all the work! 💚

dargmuesli · 2024-01-22T01:53:52Z

test/fixtures/runtime-hooks/nuxt.config.ts

+    nonce: false,
+    runtimeHooks: true,
+    headers: {
+      contentSecurityPolicy: false


@huang-julien is it required to turn off nonces and content security policy headers here?

When I keep contentSecurityPolicy headers enabled here, the headers set in the hook are not applied it seems.
When I disable contentSecurityPolicy headers here, the headers set in the hook are applied but without {{nonce}} replacement. Is that intended?

vejja · 2024-04-16T14:30:04Z

Having reviewed the source and looking at this PR again, I think the best solution would be to introduce a composable to resolve the security route rules.

Currently, each function is doing this:
// nuxt-security plugin
const { security } = getRouteRules(event)
The PR to my understanding is solving the issue of users wanting to modify this security var at runtime. In theory, a user could just modify the route rules within a nitro plugin event.context._nitro.routeRules, but the DX isn't great.

Instead, using a new composable that wraps this logic while also exposing a Nitro hook should solve the issue.
export async function resolveSecurityContext(e: H3Event) {
  const routeRules = getRouteRules(event).security
  const nitroApp = useNitroApp()
  const context = { rules: { ...routeRules } } // can't remember if this is frozen, you may need to do a clone (see klona)
  await nitroApp.hooks.hook('nuxt-security:context', context)
  return context
}
// nuxt-security plugin
const security = await resolveSecurityContext(event)
The only catch is that you don't want users running slow events in this hook. So I'd update the docs with an example like so.
export default defineNitroPlugin((nitroApp) => {
  const myCustomSecurityRules = await $fetch('/security')
  nitroApp.hooks.hook('nuxt-security:context', (context) => {
      context.rules = defu(context.rules, myCustomSecurityRules)
  })
})
Let me know what you think of this and if it solves the issue. Also feel free to name the composable / hook to whatever you think makes the most sense.

@harlan-zw
Currently trying to implement this
2 questions here

in resolveSecurityContext , 4th line should it be callHook instead of hook ? i.e.

await nitroApp.hooks.callHook('nuxt-security:context', context)

in defineNitroPlugin, I can't seem to make it async(nitroApp), which is required for await $fetch(). i.e.

export default defineNitroPlugin(async(nitroApp) => {
   ...
})

Looks like defineNitroPlugin cannot be async
Any idea on how to await fetching headers from within the Nitro plugin ?

huang-julien added 2 commits November 19, 2023 13:26

feat: allow runtime configuration for headers

65fc0d1

fix: allow setting false in override

da8461a

vercel bot deployed to Preview November 19, 2023 14:22 View deployment

Merge remote-tracking branch 'origin/main' into feat/runtime-headers

e242ccc

vercel bot deployed to Preview November 19, 2023 14:23 View deployment

dargmuesli reviewed Nov 19, 2023

View reviewed changes

docs: update doc

7207581

vercel bot deployed to Preview November 19, 2023 14:44 View deployment

huang-julien marked this pull request as ready for review November 19, 2023 16:46

huang-julien mentioned this pull request Nov 20, 2023

Move out everything from readonly runtimeConfig and allow hooks for user modification #300

Closed

harlan-zw reviewed Nov 21, 2023

View reviewed changes

src/types/index.ts Show resolved Hide resolved

harlan-zw reviewed Nov 21, 2023

View reviewed changes

src/types/index.ts Outdated Show resolved Hide resolved

dargmuesli mentioned this pull request Dec 8, 2023

fix: csp false in rc5 removes custom csp header #321

Closed

huang-julien marked this pull request as draft December 11, 2023 08:27

Merge remote-tracking branch 'origin/main' into feat/runtime-headers

6e41f10

vercel bot deployed to Preview December 11, 2023 21:45 View deployment

feat: remove runtimeHook option and refactor to context object

1827273

huang-julien force-pushed the feat/runtime-headers branch from cd70d1b to 1827273 Compare December 11, 2023 21:53

vercel bot deployed to Preview December 11, 2023 21:57 View deployment

huang-julien marked this pull request as ready for review December 15, 2023 09:49

Baroshem reviewed Dec 27, 2023

View reviewed changes

huang-julien marked this pull request as draft December 27, 2023 19:28

huang-julien added 3 commits January 10, 2024 19:44

revert: set bakc runtime hooks option

a062371

fix: add type augmentation

6acf660

chore: lint

c58491a

vercel bot deployed to Preview January 10, 2024 19:12 View deployment

docs: move doc to usage

10c6161

vercel bot deployed to Preview January 10, 2024 20:58 View deployment

huang-julien marked this pull request as ready for review January 10, 2024 21:03

vejja mentioned this pull request Jan 16, 2024

Error deploying to Cloudflare Workers after upgrade beyond rc.2 #335

Closed

Baroshem approved these changes Jan 17, 2024

View reviewed changes

Baroshem changed the base branch from main to chore/1.1.0 January 17, 2024 10:24

vejja mentioned this pull request Jan 17, 2024

Performance optimization opportunity #341

Closed

Baroshem merged commit c99d52a into Baroshem:chore/1.1.0 Jan 18, 2024
3 checks passed

dargmuesli reviewed Jan 22, 2024

View reviewed changes

Baroshem mentioned this pull request Feb 9, 2024

Are runtimeHooks only intended for the headers? #371

Closed

vejja mentioned this pull request Apr 20, 2024

feat(core): unified router context #429

Merged

6 tasks

feat: allow configuring headers in runtime #298

feat: allow configuring headers in runtime #298

Conversation

huang-julien commented Nov 19, 2023 • edited Loading

Types of changes

Description

Checklist:

vercel bot commented Nov 19, 2023 • edited Loading

huang-julien commented Nov 19, 2023 • edited Loading

dargmuesli left a comment

Choose a reason for hiding this comment

Baroshem commented Nov 20, 2023

huang-julien commented Nov 20, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

harlan-zw Nov 21, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

harlan-zw Nov 21, 2023 • edited Loading

Choose a reason for hiding this comment

huang-julien Nov 21, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Baroshem commented Dec 27, 2023

Baroshem left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

harlan-zw commented Dec 28, 2023 • edited Loading

Baroshem commented Jan 10, 2024

huang-julien commented Jan 10, 2024

huang-julien commented Jan 10, 2024 • edited Loading

harlan-zw commented Jan 15, 2024 • edited Loading

vejja commented Jan 16, 2024

Baroshem commented Jan 17, 2024

huang-julien commented Jan 17, 2024

vejja commented Jan 17, 2024

Baroshem commented Jan 18, 2024 • edited Loading

Choose a reason for hiding this comment

vejja commented Apr 16, 2024

huang-julien commented Nov 19, 2023 •

edited

Loading

vercel bot commented Nov 19, 2023 •

edited

Loading

huang-julien commented Nov 19, 2023 •

edited

Loading

harlan-zw Nov 21, 2023 •

edited

Loading

harlan-zw Nov 21, 2023 •

edited

Loading

huang-julien Nov 21, 2023 •

edited

Loading

harlan-zw commented Dec 28, 2023 •

edited

Loading

huang-julien commented Jan 10, 2024 •

edited

Loading

harlan-zw commented Jan 15, 2024 •

edited

Loading

Baroshem commented Jan 18, 2024 •

edited

Loading