user_badgeのWebhookペイロードにユーザー名を含めることはできますか?

user_badge Webhookに user_id と一緒に username を含めることは可能でしょうか?現在、user_badge イベントのペイロードは以下のようになっています:

{
  "user_badge": {
    "id": 123456,
    "granted_at": "2026-09-25T14:54:42.073Z",
    "created_at": "2026-09-26T05:34:12.965Z",
    "post_id": 234567,
    "post_number": 1,
    "badge_id": 123,
    "user_id": 456,
    "granted_by_id": -1,
    "topic_id": 56789
  }
}

user_id(および -1 ではない場合の granted_by_id)に対応するユーザー名を取得するには、/admin/users/{user_id}.json への追加のリクエストが必要です。これにより、リクエスト数が追加されるだけでなく、私の知る限り管理者権限も必要になります。

管理者権限を必要とせずに、API キーを使って特定の user_id の username を取得する方法はありますか?

特定のバッジが与えられたときにトリガーされる外部サービスを作成しようとしています。しかし、このサービスにはユーザー名が必要ですが、バッジの Webhook はユーザー ID のみ返します。:confused:

参考までに、非標準のWebhookや、追加のデータが必要な場合の私のワークアラウンドは、Workflows を通じて処理し、その結果をn8nに送信することです。

参考までに、ユーザーIDからユーザー名を取得するのはAPIを1回呼び出すだけです。もし一瞬で数千個のバッジを手動で授与するような場合を除けば、デフォルトのAPI制限内で問題なく動作するはずです。

ありがとうございます。Workflowsについて調べてみます。

それは良いニュースですね!/admin/users/{user_id}.json(管理者権限が必要)ではない、その1回のAPI呼び出しについて詳細を教えていただけますか?管理者権限を必要としないAPIキーでこれを行うためのエンドポイントを見つけることができませんでした。

管理用APIキーの問題は何ですか?これはバックグラウンドジョブのはずですよね?

最小権限の原則です。この外部サービスは別のサーバー上で実行され、その役割を果たすにはDiscourseへの読み取りアクセスのみで十分です。インフラストラクチャ全体でマスターキーが浮遊している数は、少ないほど良いです。

ここで興味深い問題が提起されます。login_required が選択されていない場合、公開フィールドのみを表示する、IDでユーザーを取得するための公開エンドポイントがなぜ存在しないのか、ということです。あると便利ではないでしょうか。なぜ作成されなかったのか気になります。あるいは、ログイン済みのユーザーのみがそのような特権を得られるようになっているのかもしれませんが、いずれにせよ、管理用エンドポイントを使わずにアクセスする方法があるべきです…

@burke より面倒な回避策としては、/groups/trust_level_0/members.json(またはより具体的なグループ)を確認し、IDからユーザーを見つける方法があります。このエンドポイントにはユーザー名も含まれているためです。

これは、すべての事項と目的において、ユーザーIDが本質的にはdiscourse内部の慣行であるためであり、より一貫して目立つユーザー名に依存することが期待されているからです。

ここで元の要求に戻りますが、Webhookはそのコンセプトに従い、ユーザーIDではなくユーザー名を送信する必要があります。

同意します!これが最良の解決策と思われます。username と granted_by_username を追加し、user_id と granted_by_id を非推奨とすることで、破壊的変更を伴わない移行期間を設けることができるでしょう。

現在、バッジがシステムによって変更された場合(つまり自動的に変更された場合)、Webhookは granted_by_id として -1 を返します。granted_by_username における同等の値は何でしょうか?

  • ""(空文字列)
  • "<system>"(ユーザー名として使用できないマジックバリュー)
  • null
  • 何もない – つまり、システム起因のイベントの場合、ペイロードから granted_by_username を省略する

null または「何もない」が最も理にかなっていると考えます。

-1は、他のユーザーと同様にユーザー名(通常はsystem)が関連付けられた有効なユーザーIDです。これを特別扱いする理由はどこにもありません。

ここでのメタ: https://meta.discourse.org/u/system/summary

なるほど、教えてくれてありがとう。つまり、自動的な変更の場合、granted_by_username は "system" になるということですね。

@putty Workflows を調べていました。バッジイベントにユーザー名が含まれるようになるまで(あるいは、Workflows のフィルタを使って、自分のサービスが知るべき変更のみを POST するように設定できるため、それがなくても)、これは素晴らしい代替手段になりそうですね!改めてありがとうございます!

Webhook では、シークレットを使用してペイロードの HMAC-SHA256 署名を生成する X-Discourse-Event-Signature ヘッダーがあり、送信元の検証が可能です。Workflows からの HTTP リクエスト(POST)に署名を付ける方法があるでしょうか?まだ見つけていないだけかもしれません。シークレットを使ってリクエストに署名できる「シークレットを使用してリクエストに署名する」といった設定があればと期待していました。最も近い機能は、header_auth クレデンシャルを追加してヘッダーにシークレットを送信すること(例:X-Discourse-Event-Secret: Discourse Rocks!)です。何もないよりはマシですが、シークレット自体を送信するのではなく、シークレットを使った署名の方が望ましいです。

残念ながら、私もヘッダー経由でシークレットを送信する方式に依存していました。おそらく @j.jaffeux がより良い代替案を提案してくれるかもしれません。そうすれば、私もすぐにその方法に切り替えます :sweat_smile:

署名を計算するためのコードステップを作成しました。Web Crypto API には HMAC-SHA256 をより簡単に計算できる機能がありますが、プロミスを使用するため、eval の内側では動作しません。そこで、AI にネイティブな JavaScript メソッドで HMAC-SHA256 を計算するコードを書いてもらい、キーに secret、値にシークレットを設定した変数を追加したところ、以下のようになったコードスクリプトが完成しました:

// 利用可能な変数:
//   $input.item.json       - 現在のアイテムの JSON データ
//   $input.all()           - すべての入力アイテムの配列
//   $json                  - $input.item.json のショートカット
//   $("NodeName").item     - 他のノードからペアリングされたアイテムにアクセス
//   $vars.KEY              - ワークフロー変数
//   $site_settings.NAME    - サイト設定
//   $execution             - 実行メタデータ (id, workflow_name, ...)
//   $current_user          - ワークフローを実行しているユーザー
//   $helpers.absoluteUrl(path) - 相対パスを絶対 URL に変換
//   console.log/warn/error - ログ出力

function hmacSha256(message, key) {
  function utf8Bytes(str) {
    const bytes = [];

    for (let i = 0; i < str.length; i++) {
      let code = str.charCodeAt(i);

      // サロゲートペアの処理
      if (
        code >= 0xd800 &&
        code <= 0xdbff &&
        i + 1 < str.length
      ) {
        const next = str.charCodeAt(i + 1);

        if (next >= 0xdc00 && next <= 0xdfff) {
          code =
            0x10000 +
            ((code - 0xd800) << 10) +
            (next - 0xdc00);
          i++;
        }
      }

      if (code <= 0x7f) {
        bytes.push(code);
      } else if (code <= 0x7ff) {
        bytes.push(
          0xc0 | (code >> 6),
          0x80 | (code & 0x3f)
        );
      } else if (code <= 0xffff) {
        bytes.push(
          0xe0 | (code >> 12),
          0x80 | ((code >> 6) & 0x3f),
          0x80 | (code & 0x3f)
        );
      } else {
        bytes.push(
          0xf0 | (code >> 18),
          0x80 | ((code >> 12) & 0x3f),
          0x80 | ((code >> 6) & 0x3f),
          0x80 | (code & 0x3f)
        );
      }
    }

    return bytes;
  }

  function rotr(x, n) {
    return (x >>> n) | (x << (32 - n));
  }

  function sha256(bytes) {
    const K = [
      0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5,
      0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
      0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3,
      0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
      0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc,
      0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
      0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7,
      0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
      0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13,
      0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
      0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3,
      0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
      0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5,
      0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
      0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208,
      0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
    ];

    const H = [
      0x6a09e667,
      0xbb67ae85,
      0x3c6ef372,
      0xa54ff53a,
      0x510e527f,
      0x9b05688c,
      0x1f83d9ab,
      0x5be0cd19
    ];

    const data = bytes.slice();
    const bitLength = data.length * 8;

    // SHA-256 パディング
    data.push(0x80);

    while ((data.length % 64) !== 56) {
      data.push(0);
    }

    // 64 ビットの大端メッセージ長を付加。
    // 通常のワークフローペイロードサイズでは、JS の整数は安全に動作します。
    const high = Math.floor(bitLength / 0x100000000);
    const low = bitLength >>> 0;

    data.push(
      (high >>> 24) & 0xff,
      (high >>> 16) & 0xff,
      (high >>> 8) & 0xff,
      high & 0xff,
      (low >>> 24) & 0xff,
      (low >>> 16) & 0xff,
      (low >>> 8) & 0xff,
      low & 0xff
    );

    const w = new Array(64);

    for (let offset = 0; offset < data.length; offset += 64) {
      for (let i = 0; i < 16; i++) {
        const j = offset + i * 4;

        w[i] =
          ((data[j] << 24) |
            (data[j + 1] << 16) |
            (data[j + 2] << 8) |
            data[j + 3]) >>> 0;
      }

      for (let i = 16; i < 64; i++) {
        const s0 =
          rotr(w[i - 15], 7) ^
          rotr(w[i - 15], 18) ^
          (w[i - 15] >>> 3);

        const s1 =
          rotr(w[i - 2], 17) ^
          rotr(w[i - 2], 19) ^
          (w[i - 2] >>> 10);

        w[i] =
          (
            w[i - 16] +
            s0 +
            w[i - 7] +
            s1
          ) >>> 0;
      }

      let a = H[0];
      let b = H[1];
      let c = H[2];
      let d = H[3];
      let e = H[4];
      let f = H[5];
      let g = H[6];
      let h = H[7];

      for (let i = 0; i < 64; i++) {
        const S1 =
          rotr(e, 6) ^
          rotr(e, 11) ^
          rotr(e, 25);

        const ch = (e & f) ^ (~e & g);

        const temp1 =
          (
            h +
            S1 +
            ch +
            K[i] +
            w[i]
          ) >>> 0;

        const S0 =
          rotr(a, 2) ^
          rotr(a, 13) ^
          rotr(a, 22);

        const maj =
          (a & b) ^
          (a & c) ^
          (b & c);

        const temp2 = (S0 + maj) >>> 0;

        h = g;
        g = f;
        f = e;
        e = (d + temp1) >>> 0;
        d = c;
        c = b;
        b = a;
        a = (temp1 + temp2) >>> 0;
      }

      H[0] = (H[0] + a) >>> 0;
      H[1] = (H[1] + b) >>> 0;
      H[2] = (H[2] + c) >>> 0;
      H[3] = (H[3] + d) >>> 0;
      H[4] = (H[4] + e) >>> 0;
      H[5] = (H[5] + f) >>> 0;
      H[6] = (H[6] + g) >>> 0;
      H[7] = (H[7] + h) >>> 0;
    }

    const result = [];

    for (let i = 0; i < H.length; i++) {
      result.push(
        (H[i] >>> 24) & 0xff,
        (H[i] >>> 16) & 0xff,
        (H[i] >>> 8) & 0xff,
        H[i] & 0xff
      );
    }

    return result;
  }

  function bytesToHex(bytes) {
    return bytes
      .map(b => b.toString(16).padStart(2, "0"))
      .join("");
  }

  const blockSize = 64;

  let keyBytes = utf8Bytes(key);
  const messageBytes = utf8Bytes(message);

  // SHA-256 のブロックサイズより長いキーは、最初にハッシュ化されます。
  if (keyBytes.length > blockSize) {
    keyBytes = sha256(keyBytes);
  }

  // キーを 64 バイトにパディングします。
  while (keyBytes.length < blockSize) {
    keyBytes.push(0);
  }

  const innerPad = new Array(blockSize);
  const outerPad = new Array(blockSize);

  for (let i = 0; i < blockSize; i++) {
    innerPad[i] = keyBytes[i] ^ 0x36;
    outerPad[i] = keyBytes[i] ^ 0x5c;
  }

  const innerHash = sha256(
    innerPad.concat(messageBytes)
  );

  const hmac = sha256(
    outerPad.concat(innerHash)
  );

  return bytesToHex(hmac);
}

const payload = JSON.stringify({
    "the-json-payload": "goes-here"
});

const signature = "sha256=" + hmacSha256( payload, $vars.secret);

return {
    "payload": payload,
    "signature": signature
};

その後、キーに X-Discourse-Workflow-Signature、値に {{ $("Code").item.json.signature }}、コンテンツタイプに JSON、リクエストボディに {{ $("Code").item.json.payload }} を持つヘッダー付きの HTTP リクエストステップが続きます。

結果として、以下のようになる HTTP リクエストが送信されます:

User-Agent: Faraday v2.14.4
Content-Length: 41
Accept: */*
Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
Content-Type: application/json
X-Discourse-Workflow-Signature: sha256=9ad2820b545013bdd18d4e7e6139624b91f576498e528201fa7759ec58dd598c

{"the-json-payload": "goes-here"}

X-Discourse-Workflow-Secret は、secret 引数の値を使用した HMAC-SHA256 署名です… 署名付き Webhook と同じですね! :slight_smile:

見た目は美しいとは言えませんが、動作しているようです。

更新: Webhook 署名のスタイルに合わせて、署名に sha256= をプレフィックスとして付けました。

かなり本物っぽいね!共有してくれてありがとう!

参考までに、このネイティブのHMAC-SHA256をWeb Crypto APIと比較して、ランダムなメッセージとキーに対して同じ結果が得られることを確認しました。シグネチャは一致しました。特殊なケースで結果が異なる可能性を完全に排除することはできませんが、本番環境で使用するのに十分な満足感があります。 :slightly_smiling_face: