跳到文章正文
Grok 实用教程

Grok多用户应用怎么传safety_identifier?稳定匿名标识与请求核对

为每个已认证用户生成稳定的不透明标识,在服务端传给Grok API;检查网关转发、跨请求一致性与…

Grok API:X搜索、文件与引用核对教程
Grok API:X搜索、文件与引用核对教程

一个网站让很多用户通过同一后端调用Grok,服务提供方看到的是同一API密钥。官方建议随请求传safety_identifier,用稳定的不透明字符串标识实际终端用户,便于在出现滥用报告时定位范围。本文讲如何由服务端生成、传递与核对,不把这个字段当登录凭证,也不承诺它能保证整个API密钥永不受限。

第一步:从服务端已认证用户取内部ID

标识必须由应用分配,不能让终端用户自己选择。先完成应用自己的身份认证,再从服务端会话中取得内部用户ID;不要直接相信网页提交的user_id或safety_identifier,否则用户可冒用他人标识,导致追踪混乱。匿名访客也要由应用管理自己的稳定标识策略。

官方要求使用内部ID的哈希或其他不透明值,不发送邮箱、手机号或显示名。哈希不是把敏感内容任意传输的理由:优先用没有个人含义的内部ID,而非对容易猜到的手机号直接计算。这个字段与API密钥用途不同,前者描述终端用户,后者授权服务端访问。

第二步:生成稳定且隔离的标识

import hashlib, hmac, json

def safety_id(internal_id, private_salt):
    message = ("grok-user:v1:" + internal_id).encode("utf-8")
    return hmac.new(private_salt, message, hashlib.sha256).hexdigest()

# 仅为本地演示,不连接API,不使用真实用户信息
demo_salt = b"local-example-only"
a = safety_id("demo-user-001", demo_salt)
b = safety_id("demo-user-002", demo_salt)
assert a == safety_id("demo-user-001", demo_salt)
assert a != b
payload = {"model": "grok-4.7", "input": "用一句话解释HTTP状态码。",
           "safety_identifier": a}
print(json.dumps(payload, ensure_ascii=False))

HMAC是这里采用的应用实现示例,官方只要求稳定且不透明,并未强制算法。生产使用独立受保护的随机盐值,在服务端密钥管理中读取,不使用示例常量。内部ID应固定格式,避免同一用户因大小写或前后空格变化产生多个标识;多租户系统还应纳入租户范围,避免相同局部ID碰撞。

第三步:在API请求体加入字段

将生成值作为请求JSON的safety_identifier,其他参数仍按所选接口规范填写。官方Responses示例使用model、input与此字段。认证头继续从服务端环境取得API密钥,不能用这个哈希替代Authorization,也不把受保护盐值作为字段内容发送出去。

POST https://api.x.ai/v1/responses
Authorization: Bearer <服务端API密钥>
Content-Type: application/json

{"model":"grok-4.7","input":"用一句话解释HTTP状态码。","safety_identifier":"服务端为当前用户生成的稳定不透明值"}

上面是字段位置示意,真正请求应使用程序生成的payload,不直接发送中文占位符。官方列出的支持范围包括Chat Completions、Responses及其流式和WebSocket模式、Deferred、Batch和gRPC相关请求;旧user字段为兼容仍可用,新接入按文档使用safety_identifier。

第四步:检查网关是否真的转发

若经过模型网关或统一SDK,先检查请求序列化后的允许字段和转发配置。不要只看业务代码里写了参数就认定已经到达上游;中间层可能过滤未知字段。可使用本地模拟服务捕获脱敏后的JSON来核对字段名和值,不为检查这个字段发起真实付费调用。

验证同一用户多次请求值相同、不同用户值不同,且切换会话后仍属于正确的已认证用户。不要每次随机生成,也不要全站统一一个标识。官方不校验格式,所以HTTP请求成功不能证明身份归属正确,应用必须自己验证映射逻辑。

第五步:管理日志与变更

内部保存必要的用户映射和访问权限,日志只记录处理问题所需信息,不能因为字段已匿名化就无限保存全部提示词。收到与某标识相关的报告时,由有权限的人在内部核对用户与请求时间,再处理具体问题,而非把哈希公开到用户列表。

盐值轮换或ID规则变更会改变标识,提前制定版本迁移与旧记录关联方式,不在每次部署随机换盐。最后验收认证来源、标识稳定性、隐私内容、网关转发和内部定位五项。该字段帮助归因具体终端用户,不能替代内容管理、速率限制或账号安全机制。

官方资料

资料核对日期:2026年11月6日。

本文地址:https://www.163264.com/19482