[BUG] v0.2.5 WebSocket connect fail

[axwfae]

Quick Summary

WebSocket connect fail

Environment & Tools

• PicoClaw Version: v.0.2.5
• Go Version: (e.g., go 1.22)
• AI Model & Provider: (e.g., GPT-4o via OpenAI / DeepSeek via SiliconFlow)
• Operating System: (e.g., Ubuntu 22.04 / macOS / Android Termux)
• Channels: (e.g., Discord, Telegram, Feishu, ...)

📸 Steps to Reproduce

1. v0.2.4 WebSocket connect ok
2. set launcher_token fix to 'clawtestoken"
3. v0.2.5 WebSocket connect fail

❌ Actual Behavior

PicoClaw Chrome Extension Connection Issue - Bug Report

Environment

• PicoClaw Version: 0.2.5
• Chrome Extension Version: 1.0.56
• NAS Docker: Running on local network (192.168.1.200)
• Gateway Port: 18790
• Launcher/API Port: 18800

Current Configuration

• Dashboard Token (launcher_token): clawtestoken
• Pico Token (from /api/pico/token): b9825e6b35e5a67444e795c2547a5110
• Gateway PID Token (from ~/.picoclaw/.picoclaw.pid): 5713189781afdcf865a26f273fbcf1fe

Problem Description

The Chrome extension cannot connect to the PicoClaw WebSocket server (both via Gateway port 18790 and Launcher port 18800). All authentication attempts fail with various HTTP errors.

Test Results

Test 1: Direct to Gateway (18790) - Simple Token

GET /pico/ws
Sec-Websocket-Protocol: token.b9825e6b35e5a67444e795c2547a5110

Result: 401 Unauthorized

Test 2: Direct to Gateway (18790) - Composed Token

GET /pico/ws
Sec-Websocket-Protocol: token.pico-5713189781afdcf865a26f273fbcf1feb9825e6b35e5a67444e795c2547a5110

Result: 400 Bad Request

Test 3: Via Launcher (18800) - Simple Token

GET /pico/ws
Authorization: Bearer clawtestoken
Sec-Websocket-Protocol: token.b9825e6b35e5a67444e795c2547a5110

Result: 400 Bad Request

Test 4: Via Launcher (18800) - Composed Token

GET /pico/ws
Authorization: Bearer clawtestoken
Sec-Websocket-Protocol: token.pico-5713189781afdcf865a26f273fbcf1feb9825e6b35e5a67444e795c2547a5110

Result: 403 Forbidden - "Invalid Pico token"

Test 5: Via Launcher (18800) - Dashboard Auth Only

GET /pico/ws?token=clawtestoken

Result: 302 Found (redirects to /launcher-login)

Expected Behavior

1. Either direct connection to Gateway (18790) should work with the simple picoToken
2. Or connection via Launcher (18800) should work when public=true is set

Code Analysis

Gateway Authentication (pkg/channels/pico/pico.go)

The authenticate() function accepts three methods:

1. Authorization: Bearer
2. Sec-Websocket-Protocol: token.
3. Query parameter token (only if AllowTokenQuery is enabled)

But the token stored in config appears to be overwritten to pico-{pidToken}{picoToken} at gateway startup.

Launcher Proxy (web/backend/api/pico.go)

The launcher proxy validates the token via picoComposedToken() which requires:

• Client sends: token.prefix+picoToken
• Launcher looks up: gateway.picoToken
• Launcher expects: tokenPrefix + gateway.picoToken == client token
• If match, transforms to: pico.PicoTokenPrefix + gateway.pidData.Token + gateway.picoToken

Questions for PicoClaw Team

1. Authentication Scheme: What is the correct authentication method for external clients (Chrome extension) to connect to the WebSocket?

2. Token Format: Should clients use:

   • Simple token: token.{picoToken} (e.g., token.b9825e6b35e5a67444e795c2547a5110)
   • Composed token: token.pico-{pidToken}{picoToken} (e.g., token.pico-5713189781afdcf865a26f273fbcf1feb9825e6b35e5a67444e795c2547a5110)

3. Gateway vs Launcher: Should clients connect directly to Gateway (18790) or through Launcher (18800)?

4. Public Mode: When launcher is set to public: true, should /pico/ws be accessible without authentication?

5. Breaking Change: This is a breaking change from older versions where only picoToken was needed. Is this intentional?

How to Reproduce

1. Start PicoClaw Docker with ports 18790 (gateway) and 18800 (launcher)
2. Configure launcher with Dashboard Token
3. Enable Pico channel and get picoToken via /api/pico/token
4. Attempt WebSocket connection from external client
5. All authentication methods fail

Additional Notes

• The old PicoClaw version worked with just the simple picoToken
• The new version requires some additional authentication that is not clearly documented
• PID token changes on every gateway restart, making it difficult for clients to connect

✅ Expected Behavior

v0.2.4 old

💬 Additional Context

[axwfae]

PicoClaw WebSocket Connection Issue - Authentication Solution

Problem Overview

External clients (such as Chrome extensions) cannot connect to the PicoClaw WebSocket server through any authentication method.

Authentication Test Results:

Connection Method	Token Format	Result
Gateway (18790)	token.picoToken	401 Unauthorized
Gateway (18790)	token.pico-{pidToken}{picoToken}	400 Bad Request
Launcher (18800)	Bearer + token.picoToken	400 Bad Request
Launcher (18800)	Bearer + token.pico-{pidToken}{picoToken}	403 Forbidden

---

Root Cause Analysis

1. Gateway Authentication Issue

File: pkg/channels/pico/pico.go

The Gateway's authenticate() function requires an exact match with the stored token, but the stored token is overwritten to:

pico-{pidToken}{picoToken}

Where pidToken changes every time the gateway restarts, making it impossible for clients to know the correct token format in advance.

2. Launcher Proxy Issue

File: web/backend/api/pico.go

The Launcher's handleWebSocketProxy() function requires:

• Client sends: token.prefix+picoToken (e.g., token.b9825e6b...)
• But actually compares with: gateway's internal picoToken value
• If not matching, returns "Invalid Pico token" error

---

Solution Recommendations

Option 1: Connect via Launcher Proxy with Authentication (Recommended)

Goal: Connect through launcher (18800) port using dashboard token authentication

Files to Modify:

1. web/backend/api/pico.go - Add query parameter authentication support

func (h *Handler) handleWebSocketProxy() http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        gateway.mu.Lock()
        ensurePicoTokenCachedLocked(h.configPath)
        gatewayAvailable := gateway.pidData != nil
        gateway.mu.Unlock()

        if !gatewayAvailable {
            http.Error(w, "Gateway not available", http.StatusServiceUnavailable)
            return
        }

        // New: Support ?token=<dashboard_token> query parameter authentication
        if queryToken := r.URL.Query().Get("token"); queryToken != "" {
            if h.validateDashboardToken(queryToken) {
                // Authentication successful, get pico token and forward
                protocol := r.Header.Get(protocolKey)
                if protocol != "" {
                    h.createWsProxy(protocol, gateway.picoToken).ServeHTTP(w, r)
                    return
                }
            }
        }

        // Existing: Authenticate via Sec-Websocket-Protocol
        prot := r.Header.Values(protocolKey)
        if len(prot) > 0 {
            origProtocol := prot[0]
            newToken := picoComposedToken(prot[0])
            if newToken != "" {
                h.createWsProxy(origProtocol, newToken).ServeHTTP(w, r)
                return
            }
        }

        http.Error(w, "Invalid Pico token", http.StatusForbidden)
    }
}

2. web/backend/api/pico.go - Add dashboard token validation function

func (h *Handler) validateDashboardToken(token string) bool {
    // Get launcher token from config and compare
    cfg, err := config.LoadConfig(h.configPath)
    if err != nil {
        return false
    }
    return token == cfg.Launcher.Token
}

Connection Flow:

Client → ws://192.168.x.x:18800/pico/ws?token=<dashboard_token>
     → Launcher validates dashboard token (query parameter)
     → Forward to Gateway and compose token
     → Gateway validates successfully
     → WebSocket connection successful

Client Code Example:

const dashboardToken = 'clawtestoken';
const picoToken = 'b9825e6b35e5a67444e795c2547a5110';

const ws = new WebSocket(
    `ws://192.168.235.200:18800/pico/ws?token=${dashboardToken}`, 
    `token.${picoToken}`
);

---

Option 2: Direct Gateway Connection (Using Dynamic Token)

Goal: Connect directly to gateway (18790) port, but need to dynamically obtain pidToken

Files to Modify:

1. Extension - Modify to obtain full authentication info from API

// Get PID token from /api/gateway/status
async function fetchWsToken() {
    const statusRes = await fetch('http://192.168.235.200:18800/api/gateway/status', {
        headers: { 'Authorization': 'Bearer clawtestoken' }
    });
    const status = await statusRes.json();
    const pidToken = status.pid_token;  // Need to add this field to API response
    
    // Get pico token from /api/pico/token
    const tokenRes = await fetch('http://192.168.235.200:18800/api/pico/token', {
        headers: { 'Authorization': 'Bearer clawtestoken' }
    });
    const tokenData = await tokenRes.json();
    const picoToken = tokenData.token;
    
    // Compose: pico-{pidToken}{picoToken}
    return `pico-${pidToken}${picoToken}`;
}

2. web/backend/api/gateway.go - Add pid_token to API response

func (h *Handler) handleGetGatewayStatus(w http.ResponseWriter, r *http.Request) {
    // ... existing logic
    
    response := map[string]interface{}{
        "pid":              pid.PID,
        "version":          version.Current().VersionString(),
        "gateway_status":   status,
        "port":             pid.Port,
        "host":             pid.Host,
        "pid_token":        pid.Token,  // New: Return PID token
    }
    
    // ... write response
}

Disadvantages:

• Need to modify server API
• pidToken changes every restart, needs to obtain each time

---

Option 3: Improve Launcher Proxy Authentication Logic

Goal: Make launcher proxy handle authentication more flexibly

Files to Modify:

1. web/backend/api/pico.go - Improve token validation logic

func (h *Handler) handleWebSocketProxy() http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        gateway.mu.Lock()
        ensurePicoTokenCachedLocked(h.configPath)
        gatewayAvailable := gateway.pidData != nil
        gateway.mu.Unlock()

        if !gatewayAvailable {
            http.Error(w, "Gateway not available", http.StatusServiceUnavailable)
            return
        }

        // Option A: Dashboard token authentication (via Authorization header)
        auth := r.Header.Get("Authorization")
        if after, ok := strings.CutPrefix(auth, "Bearer "); ok {
            if h.validateLauncherToken(after) {
                // Use stored pico token
                protocol := r.Header.Get(protocolKey)
                h.createWsProxy(protocol, gateway.picoToken).ServeHTTP(w, r)
                return
            }
        }

        // Option B: Authenticate via Sec-Websocket-Protocol (existing logic)
        prot := r.Header.Values(protocolKey)
        if len(prot) > 0 {
            origProtocol := prot[0]
            newToken := picoComposedToken(prot[0])
            if newToken != "" {
                h.createWsProxy(origProtocol, newToken).ServeHTTP(w, r)
                return
            }
        }

        http.Error(w, "Invalid Pico token", http.StatusForbidden)
    }
}

Authentication Flow:

Client → ws://192.168.x.x:18800/pico/ws
           Headers: 
           - Authorization: Bearer clawtestoken
           - Sec-Websocket-Protocol: token.b9825e6b...
     → Launcher validates Authorization (dashboard token)
     → Success, use stored picoToken to forward
     → Gateway receives composed token
     → Connection successful

---

Recommended Solution: Option 1 + Option 3 Combined

Implementation Steps:

1. Modify web/backend/api/pico.go:

   • Add support for ?token=<dashboard_token> query parameter
   • Add support for Authorization: Bearer <dashboard_token> header

2. Modify web/backend/api/gateway.go (optional):

   • Add pid_token to /api/gateway/status response

Final Connection Methods:

// Method 1: Via query parameter
const ws1 = new WebSocket(
    'ws://192.168.235.200:18800/pico/ws?token=clawtestoken', 
    'token.b9825e6b35e5a67444e795c2547a5110'
);

// Method 2: Via Authorization header
const ws2 = new WebSocket(
    'ws://192.168.235.200:18800/pico/ws', 
    'token.b9825e6b35e5a67444e795c2547a5110',
    {
        headers: { 'Authorization': 'Bearer clawtestoken' }
    }
);

---

Code Locations to Modify on Server

File	Modification	Difficulty
web/backend/api/pico.go	Add query parameter and Authorization header authentication support	Medium
web/backend/api/gateway.go	Add pid_token to API response (optional)	Easy

---

Key Points to Submit to PicoClaw Team

1. Problem: External clients cannot connect to WebSocket
2. Expectation: When connecting through launcher (18800) port, should support dashboard token authentication
3. Suggestions:
   • Make /pico/ws support ?token= query parameter
   • Make /pico/ws support Authorization: Bearer header
4. Security: These are extensions of existing authentication methods, no security risks added

[axwfae]

v0.2.6 still doesn't work!

[sky5454]

v0.2.6 still doesn't work!

Try the nightly release, that commit #2339 was not included in 0.2.6

[dominusbelial]

facing this one right now... on the docker setup i get api home/runner/work/picoclaw/picoclaw/web/backend/api/pico.go:48 > Failed to proxy WebSocket: dial tcp 127.0.0.1:18790: connect: connection refused, can't start any chat but gateway looks active, tho.

[axwfae]

v0.2.6 still doesn't work!

Try the nightly release, that commit #2339 was not included in 0.2.6

i sync nightly buld , 2025/4/10 utc+8 am 10:00 .... test fail

PicoClaw Chrome Extension Connection to picoclaw_new Issue Analysis Report

1. Problem Overview

Chrome extension cannot connect to picoclaw_new server running in NAS Docker. The extension can successfully fetch pico token, but WebSocket connection always fails.

2. Test Environment

Item	Value
Server Address	192.168.123.200
Launcher Port	18800
Gateway Port	18790
Dashboard Token	[REDACTED]
Pico Token (from API)	48044a302dfed8fda517522a9514a145

3. Test Process and Results

3.1 API Token Fetch (SUCCESS)

curl -H "Authorization: Bearer [DASH_TOKEN]" http://192.168.123.200:18800/api/pico/token

Response:
{"enabled":true,"token":"48044a302dfed8fda517522a9514a145","ws_url":"ws://192.168.123.200:18800/pico/ws"}

3.2 WebSocket Connection Tests

Method	URL	Result
Launcher Proxy + Dashboard Token	ws://192.168.123.200:18800/pico/ws?token=[DASH_TOKEN]	303 Redirect Failed
Launcher Proxy + Session Cookie	ws://192.168.123.200:18800/pico/ws + Cookie	SUCCESS (curl test)
Gateway Direct + Token Query	ws://192.168.123.200:18790/pico/ws?token=[PICO_TOKEN]	401 Unauthorized
Gateway Direct + Subprotocol	ws://192.168.123.200:18790/pico/ws with Sec-WebSocket-Protocol	401 Unauthorized

4. Root Cause Analysis

4.1 pico Token Storage Location

picoclaw_new system has two different token storage locations:

A. Launcher (18800) Memory - CORRECT:

• Obtaining method: GET /api/pico/token (requires Dashboard Token authentication)
• Token value: 48044a302dfed8fda517522a9514a145
• Launcher memory stores the correct pico token

B. Gateway (18790) Config File - MISSING OR EXPIRED:

• Config file: /root/.picoclaw/.security.yml
• Issue: Gateway loads config from config.json at startup, but sensitive info (like pico token) is stored in .security.yml
• Gateway generates new PID file (.picoclaw.pid) on each restart, but token is loaded from config file

4.2 Gateway Authentication Mechanism

Based on source code analysis (pkg/channels/pico/pico.go):

func (c *PicoChannel) authenticate(r *http.Request) bool {
    token := c.config.Token.String()
    if token == "" {
        return false  // Reject when token is empty
    }
    
    // Method 1: Authorization Bearer header
    // Method 2: Sec-WebSocket-Protocol subprotocol  
    // Method 3: Query parameter (only when allow_token_query=true)
}

Key issue: Gateway's c.config.Token is empty or doesn't match the token in Launcher memory.

4.3 Launcher Proxy Logic

/pico/ws processing flow:

1. Check if request has valid Launcher session cookie or Dashboard token
2. Validate pico token in Sec-WebSocket-Protocol subprotocol
3. Use in-memory pico token for validation (loaded from refreshPicoToken())
4. Create WebSocket proxy to Gateway after validation passes

Issue: Chrome extension cannot properly pass session cookie during WebSocket handshake.

5. Attempted Fixes

Version	Approach	Result
1.0.51	fetchPicoToken add Authorization header	Token fetch success
1.0.52	WS URL add dashboard token query param	303 Redirect
1.0.53	Direct connect to Gateway (18790)	401 Unauthorized
1.0.54	Through Launcher (18800) + token query param	303 Redirect
1.0.55	Gateway + pico token query param	401 Unauthorized
1.0.56	Through Launcher + dashboard token	303 Redirect
1.0.57	Fix syntax error	-
1.0.58	Direct connect to Gateway + subprotocol	401 Unauthorized

6. Core Issue

6.1 Gateway Cannot Get pico Token

Reason: Gateway process loads config from config.json, but pico token is stored in .security.yml. Need to call SecurityCopyFrom() to copy security config to main config, but Gateway doesn't call this method during startup.

Evidence:

# API returns config (no token)
curl -s http://192.168.123.200:18800/api/config | jq '.channels.pico'
# Output: {"enabled":true,"allow_token_query":true,...}

# Token in .security.yml
cat /root/.picoclaw/.security.yml | grep pico
# Output: pico: {token: 48044a302dfed8fda517522a9514a145}

6.2 Chrome Extension Limitations

• Cannot obtain Launcher session cookie before WebSocket handshake
• Cannot follow HTTP redirects (WebSocket handshake is special)

7. Possible Solutions

Solution 1: Modify Gateway Config Loading (RECOMMENDED)

Modify Gateway startup config loading logic to properly load pico token from .security.yml.

Locations to modify:

• pkg/gateway/gateway.go - Add cfg.SecurityCopyFrom(configPath) after config.LoadConfig()

Solution 2: Modify Launcher WebSocket Proxy Logic

Make Launcher's /pico/ws use the in-memory validated token directly when proxying, instead of relying on Gateway authentication.

Solution 3: Use Fixed pico Token

Through Docker environment variables or config file, force use of a fixed pico token instead of regenerating on each startup.

8. Conclusion

The root cause is picoclaw_new's architecture design issue, not Chrome extension code problem:

1. Launcher and Gateway use different ways to store and load pico token
2. Gateway cannot properly load pico token from .security.yml
3. Chrome extension cannot establish WebSocket connection through Launcher proxy

Recommendations:

1. Report this issue to picoclaw development team
2. Or wait for picoclaw_new new version to fix this issue
3. Current extension code is ready, only needs server-side fix to work properly

---

Report Generated: 2026-04-10
Sensitive Information Redacted

---

PicoClaw Chrome Extension 连接 picoclaw_new 问题分析报告

1. 问题概述

Chrome 插件无法连接到运行在 NAS Docker 中的 picoclaw_new 服务器。插件可以成功获取 pico token，但 WebSocket 连接始终失败。

2. 测试环境

项目	值
服务器地址	192.168.123.200
Launcher 端口	18800
Gateway 端口	18790
Dashboard Token	[已隐藏]
Pico Token (API返回)	48044a302dfed8fda517522a9514a145

3. 测试过程与结果

3.1 API Token 获取 (成功)

curl -H "Authorization: Bearer [DASH_TOKEN]" http://192.168.123.200:18800/api/pico/token

Response:
{"enabled":true,"token":"48044a302dfed8fda517522a9514a145","ws_url":"ws://192.168.123.200:18800/pico/ws"}

3.2 WebSocket 连接测试

方法	URL	结果
Launcher 代理 + Dashboard Token	ws://192.168.123.200:18800/pico/ws?token=[DASH_TOKEN]	303 重定向失败
Launcher 代理 + Session Cookie	ws://192.168.123.200:18800/pico/ws + Cookie	成功 (curl 测试)
Gateway 直连 + Token Query	ws://192.168.123.200:18790/pico/ws?token=[PICO_TOKEN]	401 Unauthorized
Gateway 直连 + Subprotocol	ws://192.168.123.200:18790/pico/ws with Sec-WebSocket-Protocol	401 Unauthorized

4. 根本原因分析

4.1 pico token 存储位置

picoclaw_new 系统中有两个不同的 token 存储位置：

A. Launcher (18800) 内存 - 正确:

• 获取方式: GET /api/pico/token (需要 Dashboard Token 认证)
• Token 值: 48044a302dfed8fda517522a9514a145
• Launcher 内存中保存了正确的 pico token

B. Gateway (18790) 配置文件 - 缺失或过期:

• 配置文件: /root/.picoclaw/.security.yml
• 问题: Gateway 启动时从 config.json 加载配置，但安全敏感信息 (如 pico token) 存储在 .security.yml
• Gateway 每次重启会生成新的 PID 文件 (.picoclaw.pid)，但 token 从配置文件加载

4.2 Gateway 认证机制

根据源代码分析 (pkg/channels/pico/pico.go):

func (c *PicoChannel) authenticate(r *http.Request) bool {
    token := c.config.Token.String()
    if token == "" {
        return false  // Token 为空时直接拒绝
    }
    
    // 方法 1: Authorization Bearer header
    // 方法 2: Sec-WebSocket-Protocol subprotocol  
    // 方法 3: Query parameter (仅当 allow_token_query=true 时)
}

关键问题: Gateway 的 c.config.Token 为空或与 Launcher 内存中的 token 不一致。

4.3 Launcher 代理逻辑

/pico/ws 处理流程:

1. 检查请求是否有有效的 Launcher session cookie 或 Dashboard token
2. 验证 Sec-WebSocket-Protocol subprotocol 中的 pico token
3. 使用内存中的 pico token 验证 (从 refreshPicoToken() 加载)
4. 验证通过后创建 WebSocket 代理到 Gateway

问题: Chrome 插件在 WebSocket 握手时无法正确传递 session cookie。

5. 已尝试的修复方案

版本	方案	结果
1.0.51	fetchPicoToken 添加 Authorization header	Token 获取成功
1.0.52	WS URL 添加 dashboard token 查询参数	303 重定向
1.0.53	直接连接 Gateway (18790)	401 Unauthorized
1.0.54	通过 Launcher (18800) + token 查询参数	303 重定向
1.0.55	Gateway + pico token 查询参数	401 Unauthorized
1.0.56	通过 Launcher + dashboard token	303 重定向
1.0.57	修复语法错误	-
1.0.58	直接连接 Gateway + subprotocol	401 Unauthorized

6. 核心问题

6.1 Gateway 无法获取 pico token

原因: Gateway 进程从 config.json 加载配置，但 pico token 存储在 .security.yml 中。需要调用 SecurityCopyFrom() 方法将安全配置复制到主配置，但 Gateway 启动时没有调用此方法。

证据:

# API 返回的配置 (无 token)
curl -s http://192.168.123.200:18800/api/config | jq '.channels.pico'
# Output: {"enabled":true,"allow_token_query":true,...}

# .security.yml 中的 token
cat /root/.picoclaw/.security.yml | grep pico
# Output: pico: {token: 48044a302dfed8fda517522a9514a145}

6.2 Chrome 插件的局限性

• 无法在 WebSocket 握手前获取 Launcher session cookie
• 无法在 HTTP层面进行重定向跟随 (WebSocket 握手是特殊的)

7. 可能的解决方案

方案 1: 修改 Gateway 配置加载 (推荐)

修改 Gateway 启动时的配置加载逻辑，确保正确从 .security.yml 加载 pico token。

需要修改的位置:

• pkg/gateway/gateway.go - 在 config.LoadConfig() 后添加 cfg.SecurityCopyFrom(configPath)

方案 2: 修改 Launcher 的 WebSocket 代理逻辑

让 Launcher 的 /pico/ws 在代理请求时直接从内存使用已验证的 token，而不是依赖 Gateway 的认证。

方案 3: 使用固定的 pico token

通过 Docker 环境变量或配置文件，强制使用固定的 pico token，而不是每次启动时重新生成。

8. 结论

问题的根本原因是 picoclaw_new 的架构设计问题，而非 Chrome 插件代码问题：

1. Launcher 和 Gateway 使用不同的方式存储和加载 pico token
2. Gateway 无法正确加载 .security.yml 中的 pico token
3. Chrome 插件无法通过 Launcher 代理成功建立 WebSocket 连接

建议:

1. 报告给 picoclaw 开发团队此问题
2. 或等待 picoclaw_new 新版本修复此问题
3. 当前插件代码已准备好，只需服务端修复后即可正常工作

---

报告生成时间: 2026-04-10
敏感信息已脱敏