[Bug]: xiaohongshu bare note ID no longer resolves reliably, signed URL still works

[Astro-Han]

Description

opencli xiaohongshu note <bare-note-id> and opencli xiaohongshu comments <bare-note-id> are still blocked by Xiaohongshu risk control on current main, even after fix(xiaohongshu): harden anti-detection flows (#980).

The remaining problem is narrower than the anti-detection patch itself. The real failure is the bare note ID resolution path.

Verified behavior:

• A full signed note URL with xsec_token works.
• A bare note ID fails.
• A tokenless direct note URL fails the same way.
• A signed URL recovered from user/profile context works for both note and comments.

Current helper logic still turns a bare note ID into a tokenless URL in clis/xiaohongshu/note-helpers.js:
https://www.xiaohongshu.com/search_result/<id>

That assumption appears stale now.

Steps to Reproduce

1. Run npx tsx src/main.ts xiaohongshu search 美食 --limit 1 -f json
2. Copy one returned full note URL with xsec_token
3. Run npx tsx src/main.ts xiaohongshu note "<full-url-with-xsec_token>" -f json
4. Observe that it succeeds
5. Run npx tsx src/main.ts xiaohongshu note 69db64f1000000001d01a329 -f json
6. Run npx tsx src/main.ts xiaohongshu comments 69db64f1000000001d01a329 -f json
7. Observe that both fail on a Xiaohongshu restriction/security page

Diagnostic repro for the failing bare-ID path:

OPENCLI_DIAGNOSTIC=1 npx tsx src/main.ts xiaohongshu note 69db64f1000000001d01a329 -f json

Observed final URL pattern:

https://www.xiaohongshu.com/website-login/error?...error_code=300017...

Observed page text includes:

安全限制
访问链接异常
300017

Expected Behavior

If bare note ID support is still intended, OpenCLI should resolve the note through a valid signed path before attempting note/comments extraction.

If that is no longer technically reliable, xiaohongshu note/comments/download should explicitly require a signed full URL or recoverable context instead of assuming a bare note ID is sufficient.

OpenCLI Version

1.7.2

Node.js Version

Other (25.9.0)

Operating System

macOS

Logs / Screenshots

ok: false
error:
  code: UNKNOWN
  message: 'Xiaohongshu security block: the note detail page was blocked by risk control.'
  exitCode: 1

Additional verified evidence:

• xiaohongshu note "https://www.xiaohongshu.com/user/profile/<userId>/<noteId>?xsec_token=...&xsec_source=pc_user" succeeds
• xiaohongshu comments "https://www.xiaohongshu.com/user/profile/<userId>/<noteId>?xsec_token=...&xsec_source=pc_user" succeeds
• the existing extraction logic works once the entry URL is signed
• the unresolved architectural gap is note ID -> signed URL resolution

[junyussh]

I also met the same problem. If the URL is without xsec_token, it will show the security block message and make you use an app to view the note. But if we bear the xsec_token, the note can be viewed. I think it's an easy issue to fix.

[kagura-agent]

This appears to be resolved by #996 (merged as cd48917), which now requires full signed URLs with xsec_token instead of accepting bare note IDs. The buildNoteUrl() helper in note-helpers.js now throws an ArgumentError with a clear hint when a bare ID is passed.

Can this be closed?