本文へ移動
cccskills
無料GitHub で公開

nip98-url-query-param-mismatch

Fix NIP-98 HTTP authentication 401 errors caused by URL mismatch between the `u` tag and what the server expects. Use when: (1) NIP-98 auth returns 401 with "URL mismatch" error, (2) Token creation succeeds but server rejects authentication, (3) Server logs show expected vs actual URL difference. CRITICAL: Server implementations vary - some strip query params, some don't. Check the actual error message to determine which behavior applies.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md3.6 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

NIP-98 URL Query Parameter Mismatch

Problem

NIP-98 HTTP authentication fails with 401 Unauthorized even though the token is created successfully and the signature is valid. The actual cause is a URL mismatch between the u tag in the signed event and what the server expects.

Context / Trigger Conditions

  • Server returns 401 Unauthorized for NIP-98 protected endpoints
  • Logs show token creation succeeded (event signed and validated)
  • Error response contains "URL mismatch" with expected vs actual URLs
  • The URLs differ only by query parameters

Example error response:

{"error":"Auth failed: URL mismatch: expected .../notifications, got .../notifications?limit=50"}

Root Cause

The NIP-98 spec says:

The u tag MUST be exactly the same as the absolute request URL (including query parameters).

But server implementations vary:

  • Some servers follow the spec strictly (require query params in u tag)
  • Some servers normalize URLs by stripping query params before validation
  • You MUST match what your specific server does

Solution

Step 1: Add logging to see the actual error

} else if (response.statusCode == 401) {
  Log.error(
    'NIP-98 auth failed (401)\n'
    'URL: $url\n'
    'Response: ${response.body}',  // <-- This reveals the actual issue
    ...
  );
}

Step 2: Check the error message

  • If error says "expected .../path?params, got .../path" → Include query params
  • If error says "expected .../path, got .../path?params" → Strip query params

Step 3: Adjust URL normalization accordingly

For servers that STRIP query params (like Divine Relay):

final uri = Uri.parse(url);
// Server strips query params before NIP-98 validation
final normalizedUrl = '${uri.scheme}://${uri.host}${uri.path}';

For servers that REQUIRE query params (per NIP-98 spec):

final uri = Uri.parse(url);
final normalizedUrl = uri.hasQuery
    ? '${uri.scheme}://${uri.host}${uri.path}?${uri.query}'
    : '${uri.scheme}://${uri.host}${uri.path}';

Verification

  1. After the fix, the URLs in the u tag should match what server expects
  2. The 401 error should be replaced by successful authentication (200)
  3. Check logs to confirm URL matching

Example

Divine Relay behavior (strips query params):

  • Request URL: https://relay.dvines.org/api/users/abc/notifications?limit=50
  • Server validates against: https://relay.dvines.org/api/users/abc/notifications
  • u tag must be: https://relay.dvines.org/api/users/abc/notifications

Notes

  • The NIP-98 spec is clear about including query params, but not all servers follow it
  • Always check the actual error response to determine server behavior
  • When in doubt, try both approaches and see which works
  • Consider filing a bug with servers that don't follow the spec

References

  • NIP-98 HTTP Auth Specification
  • Spec quote: "The u tag MUST be exactly the same as the absolute request URL (including query parameters)"
  • Reality: Server implementations vary, always check actual behavior

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Fix ArgoCD ExternalSecret deployment failing with "namespace X is not permitted in project Y". Use when: (1) ExternalSecret shows OutOfSync in ArgoCD but won't sync, (2) ArgoCD application status shows "namespace X is not permitted in project 'infrastructure'", (3) ExternalSecret targets a namespace managed by a different ArgoCD project, (4) Using apps-of-apps pattern with separate infrastructure and application projects.

日本語の概要は準備中です。原文の説明を表示しています。

divinevideo/divine-mobile2662026年10月13日 更新

Art direction for any content — reads text, PDF, Word, HTML, PPT, then proposes 2-3 creative directions with photography style, mood, and visual language. After selection, generates AI image prompts and visual briefs section-by-section. Use when the user shares content and needs visual direction, image sourcing, or creative direction for any material.

日本語の概要は準備中です。原文の説明を表示しています。

divinevideo/divine-mobile2662026年10月13日 更新

Fix "Null check operator used on a null value" errors when an object is set to null during an async await. Use when: (1) Object reference is nullified while awaiting, (2) Code accesses object with ! after await returns, (3) Cancel/dispose operations run concurrently with async operations on same object. Solution: capture local reference before await.

日本語の概要は準備中です。原文の説明を表示しています。

divinevideo/divine-mobile2662026年10月13日 更新

Add custom metadata headers (x-amz-meta-*) to AWS v4 signed requests for GCS S3-compatible API. Use when: (1) Adding custom metadata to GCS uploads via S3 API, (2) Getting signature mismatch errors after adding new headers, (3) x-amz-meta-* headers being ignored or causing 403 errors. Custom headers MUST be included in canonical headers and signed headers list.

日本語の概要は準備中です。原文の説明を表示しています。

divinevideo/divine-mobile2662026年10月13日 更新

Fix password/secret authentication failures caused by trailing newlines when creating Google Cloud secrets (or similar) with bash here-strings. Use when: (1) Password authentication fails with correct password, (2) Secret created with `<<< "value"` syntax, (3) Error like "password authentication failed" or "invalid token" despite correct value. Bash here-strings (`<<<`) add a trailing newline that corrupts secrets.

日本語の概要は準備中です。原文の説明を表示しています。

divinevideo/divine-mobile2662026年10月13日 更新

Fix silent video/media processing failures caused by URL extraction code that filters on file extensions (.mp4, .webm, .webp). Use when: (1) Media moderation, transcoding, or analysis silently skips files from Blossom or content-addressed storage servers, (2) URL extraction from Nostr event tags (imeta, r tags) drops URLs without recognized extensions, (3) CDN fallback URLs append .mp4 but the actual server uses extensionless content-addressed paths like /{sha256}. Common in Nostr video events (kind 34236) where different clients use different URL formats.

日本語の概要は準備中です。原文の説明を表示しています。

divinevideo/divine-mobile2662026年10月13日 更新

divinevideo のスキルをすべて見る

このスキルの問題を報告する