Nuxt 3插件访问私有runtimeConfig报错，公开配置存安全顾虑

我有一个用于在页面中获取数据的简单Nuxt 3插件，需要访问API凭证。考虑到这些凭证属于私有信息，我认为它们不应放在公开配置中，所以配置如下：

runtimeConfig: {
    contentful: {
        environment: '',
        spaceId: '',
        accessToken: ''
    },
},

在初始化API客户端的插件中，代码如下：

import { createClient } from "contentful";

export default defineNuxtPlugin(nuxtApp => {

  const runtimeConfig = useRuntimeConfig()

  const client = createClient({
    space: runtimeConfig.contentful.spaceId,
    accessToken: runtimeConfig.contentful.accessToken,
    environment: runtimeConfig.contentful.environment
  })

  console.log(runtimeConfig.contentful)

  return {
    provide: {
      contentful: client
    }
  }
})

这些变量在SSR环境中可以正常获取（console语句已验证），但在浏览器中会抛出以下错误：

Expected parameter space

at createClient (http://localhost:63921/_nuxt/node_modules/.vite/deps/contentful.js?v=18c196e8:5296:11)
at http://localhost:63921/_nuxt/plugins/example.js:10:18
at fn (http://localhost:63921/_nuxt/node_modules/nuxt/dist/app/nuxt.mjs?v=18c196e8:146:27)
...

如果改用公开runtimeConfig（即放在public字段下）则可以正常运行，但我认为这样不安全，因为会暴露API访问令牌。请问我的理解是否有误？

问题分析与解决方案 #

你的理解完全正确：私有runtimeConfig中的变量仅在服务端（SSR渲染/SSG构建阶段）可用，浏览器端无法读取这些私有配置，这就是为什么浏览器中会出现Expected parameter space错误——此时runtimeConfig.contentful的所有字段都是undefined。

而将凭证放在public字段下确实会导致敏感信息暴露，绝对不可行。要解决这个问题，核心是避免在浏览器端直接初始化需要私有凭证的API客户端，通过Nuxt的服务端路由代理所有API请求：

1. 创建服务端代理路由 #

在server/api目录下新建contentful/[...].ts（或.js）文件，用于代理Contentful的API请求：

import { createClient } from "contentful";

export default defineEventHandler(async (event) => {
  const runtimeConfig = useRuntimeConfig();
  // 服务端可正常访问私有runtimeConfig
  const client = createClient({
    space: runtimeConfig.contentful.spaceId,
    accessToken: runtimeConfig.contentful.accessToken,
    environment: runtimeConfig.contentful.environment
  });

  // 解析请求路径，匹配对应的Contentful操作
  const requestPath = event.context.params?.["*"];
  
  // 示例：处理获取条目请求，可根据需求扩展其他操作
  if (requestPath === "entries") {
    const queryParams = getQuery(event);
    return await client.getEntries(queryParams);
  }

  // 可添加更多Contentful API方法的处理逻辑，比如getEntry等
  throw createError({ statusCode: 404, message: "Unsupported Contentful API endpoint" });
});

2. 修改插件，通过代理请求数据 #

不再在插件中直接初始化Contentful客户端，而是封装调用服务端路由的方法：

export default defineNuxtPlugin(nuxtApp => {
  const contentfulClient = {
    // 封装获取条目的方法
    getEntries: async (query = {}) => {
      return await $fetch("/api/contentful/entries", { query });
    },
    // 按需封装其他需要的方法，比如getEntry
    getEntry: async (entryId) => {
      return await $fetch(`/api/contentful/entries/${entryId}`);
    }
  };

  return {
    provide: {
      contentful: contentfulClient
    }
  };
});

3. 保留原有私有RuntimeConfig配置 #

你的runtimeConfig配置无需修改，服务端路由运行在Node.js环境中，能正常读取私有配置里的凭证，不会暴露给浏览器。

额外说明 #

• Contentful的令牌分为交付令牌和管理令牌：交付令牌本身用于拉取公开内容，是可以安全公开的；但管理令牌具备修改内容的权限，必须严格放在私有配置中，通过服务端代理使用。如果你的场景仅需获取公开内容，也可以将交付令牌放在public字段下直接在客户端初始化客户端，但管理令牌绝对不能这么做。
• 若需要在客户端使用预览模式，可以在服务端生成临时的、权限受限的预览令牌，再传递给客户端使用。

内容的提问来源于stack exchange，提问作者Russ Back