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

[huang-julien]

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

This is more like a RFC than a feature request

related to #231 #233 #298 #258

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.

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]

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]

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

[huang-julien]

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

#298 (comment) @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]

Ok, makes sense for me.

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