298 is introducing a new option called runtimeHooks. This would let users the ability to change their configuration at runtime with `nuxt-security:...` hooks.

The idea is to take out the runtime configuration from runtimeConfig which is currently readonly and having a writable object (or cache) to set the runtime configuration.

This will be send to event.context.security and all middlewares of nuxt-security will find their configuration in this object to know what they should do.

Now why doing this ?

A lot of our users are company users, some of them are storing their configuration in remote services such as Azure AppConfig, keyvaults.... So this would allow users to retrieve their configuration at server startup, probably cache it, refreshing it with an interval without having to actually re-deploy their server.

What would it look like ?

I think using nitro hooks would definitively give a maximum of DX to the user.

the current signature of nuxt-security:headers is (e: 'nuxt-security:headers', route: string, config: SecurityHeaders) => void

and we could probably add more hooks that looks like nuxt-security:headers to change other configuration.

Describe alternatives you've considered

Additional context

Baroshem commented 11 months ago

Very interesting feature idea!

I myself am using Google Secret Manager for configuration but it is more for variables like API keys.

However, I think that this feature should be rather an option in the config that could be enabled and then the configuration could be loaded from the hook rather than changing it completely for everyone IMO as it could lead to potential breaking changes or regressions (I may be wrong here so please correct me).

Baroshem commented 11 months ago

@huang-julien what do you think about my comment above? :)

huang-julien commented 11 months ago

Yes, so the idea was to make it optionnal in #298 . This would give to users the choice between both methods of configuration, using both would even be possible since runtime hooks would simply override the old configuration

https://github.com/Baroshem/nuxt-security/pull/298#discussion_r1400018411 @harlan-zw probably thinks that making it optionnal doesn't add any value. Ican agree with @harlan-zw since this isn't supposed to bring any breaking change. It instead adds a new feature

Baroshem commented 10 months ago

Ok, makes sense for me.

Would you be open for creating a PR with that solution? We could then test this out properly :)

Baroshem / nuxt-security

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

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

298 is introducing a new option called runtimeHooks. This would let users the ability to change their configuration at runtime with `nuxt-security:...` hooks.

Now why doing this ?

What would it look like ?

Describe alternatives you've considered

Additional context

Baroshem / nuxt-security

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

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

298 is introducing a new option called runtimeHooks. This would let users the ability to change their configuration at runtime with nuxt-security:... hooks.

Now why doing this ?

What would it look like ?

Describe alternatives you've considered

Additional context

298 is introducing a new option called runtimeHooks. This would let users the ability to change their configuration at runtime with `nuxt-security:...` hooks.