CubeJS多租户实现：如何基于JWT信息为不同客户端分配对应BigQuery数据集？

我刚解决过几乎一模一样的CubeJS + BigQuery多租户场景问题，给你梳理下问题根源和正确的解决方案：

首先，你踩的第一个坑是COMPILE_CONTEXT的使用场景——它是Schema编译阶段的全局变量，服务器启动时就会把Schema编译好，之后所有请求都会复用这个编译后的版本，所以它根本没法实现每个请求动态切换数据集的需求，完全是用错了工具。

然后是SECURITY_CONTEXT的问题，你直接用${SECURITY_CONTEXT.dataset_id}导致变成[object Object]，是因为在Schema编译时，SECURITY_CONTEXT还不是运行时的实际对象，它只是CubeJS用来标记运行时变量的占位符，直接用JS模板字符串拼接的话，会把这个占位符对象转成字符串，自然就出问题了。

正确的实现方式 #

1. 先确保SECURITY_CONTEXT正确传递

首先要在你的cube.js配置文件里，通过checkAuth函数解析JWT，把dataset_id放到请求的securityContext中：

const jwt = require('jsonwebtoken');

module.exports = {
  checkAuth: async (req, res, next) => {
    // 从请求头获取JWT
    const authHeader = req.headers.authorization;
    if (!authHeader) {
      return res.status(401).send('Unauthorized');
    }
    
    const token = authHeader.split(' ')[1];
    try {
      const decoded = jwt.verify(token, process.env.JWT_SECRET);
      // 把dataset_id放到securityContext里
      req.securityContext = { dataset_id: decoded.dataset_id };
      next();
    } catch (err) {
      return res.status(401).send('Invalid token');
    }
  },
  // 其他CubeJS配置...
};

2. 在Schema中正确引用SECURITY_CONTEXT

有两种可靠的写法：

写法一：使用CubeJS内置的模板语法（推荐，简洁）

CubeJS支持在sql字段中用{{ 变量 }}的模板语法引用运行时上下文：

cube(`Sessions`, {
  sql: `SELECT * FROM {{ SECURITY_CONTEXT.dataset_id }}.sessions_export`,
  measures: {
    count: {
      sql: `Status`,
      type: `count`,
    },
  }
})

写法二：使用箭头函数动态生成SQL（适合复杂逻辑）

如果需要更复杂的动态逻辑，可以用箭头函数返回SQL，此时this会指向当前的Cube上下文，能直接访问securityContext：

cube(`Sessions`, {
  sql: () => {
    const datasetId = this.securityContext.dataset_id;
    // 这里可以加一些校验逻辑，比如判断datasetId是否合法
    if (!datasetId) {
      throw new Error('Missing dataset_id in security context');
    }
    return `SELECT * FROM ${datasetId}.sessions_export`;
  },
  measures: {
    count: {
      sql: `Status`,
      type: `count`,
    },
  }
})

如何调试SECURITY_CONTEXT #

调试这个变量有两个简单方法：

1. 在checkAuth中打印：直接在checkAuth函数里加console.log('Current Security Context:', req.securityContext)，这样每次请求都会在Cube服务器日志里看到当前的上下文内容。
2. 加一个调试用的Cube：在Schema里创建一个专门用来输出上下文的Cube，查询它就能看到SECURITY_CONTEXT的实际内容：

cube(`DebugSecurityContext`, {
  sql: `SELECT 1 AS dummy`,
  measures: {
    contextJson: {
      sql: `JSON_STRINGIFY('{{ JSON.stringify(SECURITY_CONTEXT) }}')`,
      type: `string`,
    },
  }
})

然后用CubeJS Playground查询这个Cube的contextJson measure，就能看到完整的SECURITY_CONTEXT内容了。

其他可选方案 #

如果你的场景更复杂，比如需要对租户做更多隔离，也可以考虑CubeJS的多租户模式，用tenantId映射到对应的dataset_id，但核心逻辑还是通过securityContext传递租户标识，本质和上面的方案是一致的。

内容的提问来源于stack exchange，提问作者Ben Holmquist