dynamic runtime environment variables

[janesser]

While striving for immutable build artifacts we came across some possible improvement points.

First let me explain the motivation behind "immutable build artifact". Alongside of the stages like e,g, DEV, TEST, QA, UAT, PROD the configuration changes, as an example nuxt-axios API_URL and API_BROWSER_URL. Ideally this can be injected by env vars, which pretty much fits the kubernetes way of dealing with configuration.

Presently a work-around can be achieved with help of https://github.com/samtgarson/nuxt-env, which does a decent job in providing needed injection mechanism. The down-side is that no nuxt-plugin by default goes for this.$env, which drives one in a lot of customizing of plugins. Not to mention the broken upgrade ease.

Can you imagine a way to support this natively in some of the next nuxt releases?

_{This question is available on Nuxt community (#c8719)}

[pi0]

Hi @janesser. I've transferred issue from RFC to here because it is more an enhancement discussion.

Values passed to the env section of nuxt.config will be replaced by a webpack plugin during the build. Would you please elaborate more what you expect from storing it in build artifact?

[vhf]

I also ran into this problem, here is one of my example case:

I'm using nuxtjs auth module with some OAuth API. Here is what the config looks like: https://auth.nuxtjs.org/reference/providers/github , in nuxt.config.js:

auth: {
  strategies: {
      github: {
        client_id: '...',

I'd like to build my app once and deploy it many times with different configuration values. This cannot be done because client_id: process.env.FOO_CLIENT_ID will be replaced at build time and the build-time value will be written in the build artifacts.

Here you couldn't build your app in a container and deploy it with different FOO_CLIENT_ID values, you would have to build the app each time you start a container.

I hope this makes the benefits of having nuxt projects configurable at runtime a bit clearer.

[aldarund]

@pi0 its more about have runtime env vars like in the module that is linked. E.g. build once deploy to different environments same artifact, isntead of building each time for each env ( e.g. staging, test, production etc )

[pi0]

I see the point. And auth and axios are probably best examples for such need. However, this is a duplicate topic and issue was discussed here is a short brief of status:

• 1. process.env.* from server side is runtime configurable. axios module supports it for example for API_URL
• 2. process.env.* from client-side when running in SSR mode, is only changeable if we somehow pass it to nuxtState. The simplest way would be using a store module.
• 3. process.env.* from client-side when running in SPA or Static generated mode, is only changeable by doing an API call.

Having built-in support for case (2) could be possible but potentially opens a way to critical security holes and is only usable for SSR users.

Regarding case (3) also could be possible to store app config in a json file inside static dir and make client to download it on each visit. Has overhead but at least makes it somehow possible.

[janesser]

@pi0 can you link the original discussion that you refer too, please?

@vhf @aldarund thanks for supporting the need.

regarding the security, i am confident that docker envvars are sufficiently safe.
having something in javascript either hard-coded or dynamically refreshed is also in the same security class. Maybe i miss some attack vectors.

i felt like you hit the sensible point where it came to the way that webpack4 build routine is instrumented. Probably the present behaviour is at least partially inherited.

regarding possible solutions, did you check nuxt-env? by my experience it covers SSR plus non-SSR in a consistent way, not sure how it is solved internally. //cc @samtgarson
EDIT: it uses nuxtState around here: https://github.com/samtgarson/nuxt-env/blob/master/lib/plugin.js

ill try to collect some insight on webpack4 and eventually read through the internals of nuxt-env to give you some additional pointers.

[samtgarson]

@janesser in the meantime open an issue for any confusing things you're hitting—I picked $env as it seemed appropriate but we can look at changing it or allowing it to be dynamic pretty easily.

@pi0 all I do is use a middleware to add the process.env values onto the req object, then a plugin which uses nuxtState to read from req and inject them onto the context.

Would be great to have this natively, it's currently impossible to use Nuxt in any kind of containerised, multi-environment setup with the existing native setup, or at least anywhere where the production environment could vary from the build environment.

[samtgarson]

(non SSR and SPA are still scenarios that I don't think nuxt-env covers super smoothly, but it's OK...)

[pi0]

Mainly discussed in #618.

We are aware of @samtgarson nuxt-env project. That's implementing (2) method which would be useful for users that want it. It is more than qualified to be a nuxt-community project 👍

About security matter. Docker can't prevent one accidentally passing client_secrect to the user's browser window. It is the user's responsibility to be aware and ensure that.

/cc @manniL @aldarund

[janesser]

About secrets retention, check this one: samtgarson/nuxt-env#9

To wrap up, is there a way to make process.env as consumed by default from nuxt-plugins in the same way as process.$env?