当用户要生成连接 token,或要为某个 peer_id (设备) 生成 token 时使用;默认通过 TiRTC DevTools CLI 从环境变量读取 access_id 和 secret_key,并返回 token 与二维码 PNG 路径。
用户侧最小输入只需要:
TIRTC_CONN_ACCESS_IDTIRTC_CONN_SECRET_KEYpeer_idSkill 内部默认:
local_id,则默认使用同一个 peer_id 作为 local_idopenapi_entry、service_entry、TTL、二维码参数默认不要求用户手动传递,只有在用户明确提出时才展开access_id 和 secret_key,而不是直接从命令位置参数接收。TIRTC_CONN_ACCESS_ID、TIRTC_CONN_SECRET_KEY。--access-id、--secret-key 传入。peer_id;local_id 缺省时走内部默认值,不额外打扰用户。access_id、secret_key 直接写入源码、文档、截图或长期配置文件。tokenpayload 或 payloadJsonqrCodePngPathpeer_idlocal_iduser_ttl_secondschannel_ttl_secondsgenerated_at--json 模式运行且宽度足够,可附带 ASCII 二维码open <qrCodePngPath> 后回报结果结果转述必须遵守:
channel_ttl_seconds 总结成“整个 token 的有效期”user_ttl_seconds=<...>、channel_ttl_seconds=<...>、generated_at=<...>npm install -g tirtc-devtools-cli@latest,确保使用的是最新正式版;不要复用未知旧版本peer_id;access_id、secret_key 默认由 CLI 自己从环境变量读取local_id,内部默认令 local_id = peer_id--json 调用 tirtc-devtools-cli token issue <peer_id>,拿到 token 与 qrCodePngPathTIRTC_CONN_ACCESS_ID、TIRTC_CONN_SECRET_KEYopen <qrCodePngPath>当 access_id / secret_key 已在环境变量中时,推荐命令形态:
export TIRTC_CONN_ACCESS_ID="<ACCESS_ID>"
export TIRTC_CONN_SECRET_KEY="<SECRET_KEY>"
tirtc-devtools-cli --json token issue \
"<PEER_ID>"
如果用户明确要求直接在终端看 ASCII 二维码,可去掉 --json,并按需加入:
--qr-error-correction-level <L|M|Q|H>--ascii-max-columns <columns>消费侧工具只需要把诉求收成这类最小表达:
peer_id 生成一个 tokenSkill 内部应自动做这些事:
TIRTC_CONN_ACCESS_ID、TIRTC_CONN_SECRET_KEYnpm install -g tirtc-devtools-cli@latestpeer_idlocal_id = peer_id--json 调用 CLIecho、printenv 或其他 preflight 命令探测环境变量;直接调用 CLI,让 CLI 自己做缺失校验token、qrCodePngPath、peer_id、local_id、user_ttl_seconds、channel_ttl_seconds、generated_atopen <qrCodePngPath>npm install -g tirtc-devtools-cli@latest 后重试TIRTC_CONN_ACCESS_ID / TIRTC_CONN_SECRET_KEY,或在其明确同意时显式提供一次性参数qrCodePngPath