Можно ли добавить имена пользователей в webhook-запрос user_badge?

Есть ли шанс, что вебхуки user_badge могли бы включать username вместе с user_id? Сейчас полезная нагрузка (payload) для события 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 (и для granted_by_id, если он не равен -1), требуется дополнительный запрос к /admin/users/{user_id}.json. Это не только требует дополнительных запросов, но и, насколько я понимаю, требует прав администратора.

Есть ли способ получить username для заданного user_id с помощью API-ключа без необходимости в правах администратора?

Я создаю внешний сервис, который, как я надеялся, должен срабатывать при присвоении определенных значков; однако ему нужно имя пользователя, а вебхуки значков возвращают только идентификаторы пользователей. :confused:

К слову, моим обходным решением для нестандартных вебхуков или когда мне нужны дополнительные данные, является использование Workflows, а затем отправка именно их в n8n.

Кстати, получение имени пользователя по его ID — это всего один вызов API. Если вы не присваиваете тысячи значков вручную за один момент, стандартных лимитов API вам должно хватить.

Спасибо! Я посмотрю, как работают Workflows.

Это отличные новости! Не могли бы вы уточнить детали этого одного вызова API, который не является /admin/users/{user_id}.json (требующим прав администратора)? Я не смог найти эндпоинт, который позволял бы сделать это с помощью API-ключа без прав администратора.

В чём проблема с админ-ключом API? Это же, наверное, фоновая задача?

Принцип минимальных привилегий. Эта внешняя служба будет работать на другом сервере и нуждается только в доступе на чтение к Discourse для выполнения своей задачи. Чем меньше мастер-ключей курсирует по инфраструктуре, тем лучше.

Это поднимает интересный вопрос: почему нет публичного эндпоинта для получения пользователя по его ID, который отображал бы только публичные поля, если не выбран параметр login_required. Было бы полезно, не правда ли? Неужели это не сделали? Или, возможно, такая привилегия доступна только зарегистрированным пользователям, но в любом случае должен существовать способ получить к этому доступ без использования административного эндпоинта…

@burke Более обременительным обходным решением было бы обратиться к /groups/trust_level_0/members.json (или к любой более конкретной группе) и найти пользователя по его ID, поскольку там также содержится имя пользователя.

Это связано с тем, что пользовательские идентификаторы (user IDs) во всех случаях и для всех целей являются, по сути, внутренним соглашением в Discourse, и мы ожидаем, что вы будете полагаться на имена пользователей, которые значительно более распространены во всех отношениях.

И вот мы возвращаемся к исходному запросу. Вебхук должен следовать этой концепции и отправлять имя пользователя, а не его идентификатор.

Согласен! Это кажется лучшим решением. Добавление username и granted_by_username и объявление user_id и granted_by_id устаревшими могли бы обеспечить период плавного перехода без нарушений совместимости.

В настоящее время, если значок изменяется системой (т. е. автоматически), вебхук возвращает granted_by_id со значением -1. Что будет эквивалентом для granted_by_username?

  • "" (пустая строка)
  • "<system>" (магическое значение, которое не может быть именем пользователя)
  • null
  • Ничего – т. е. опустить granted_by_username из полезной нагрузки, если это было системное событие

Я бы предположил, что null или отсутствие поля имели бы наибольший смысл.

-1 — это на самом деле действительный идентификатор пользователя, у которого есть имя пользователя (обычно system), как и у любого другого пользователя. Нет никаких причин относиться к нему иначе.

Вот здесь, на meta https://meta.discourse.org/u/system/summary

О. Спасибо, что научили меня этому. Значит, в случае автоматических изменений granted_by_username будет просто равно "system".

@putty Я изучаю Workflows. Пока/если события бейджей не включают имена пользователей (а может быть, это не имеет значения, так как я могу использовать фильтры в Workflows, чтобы отправлять POST-запросы только с теми изменениями, о которых мой сервис должен узнать), это выглядит как отличный альтернативный вариант! Спасибо ещё раз!

С вебхуками есть заголовок X-Discourse-Event-Signature с подписью HMAC-SHA256 от полезной нагрузки, использующей секрет, что позволяет мне проверять отправителя. Есть ли шанс, что существует способ подписать HTTP-запросы (POST) из Workflows? Возможно, я просто ещё не нашёл это. Я надеялся, что будет настройка вроде «Подписать запрос с использованием секрета», которую я мог бы включить и указать секрет. Ближайшее, что я видел, — это добавление учетных данных header_auth для отправки секрета в заголовке (например, X-Discourse-Event-Secret: Discourse Rocks!). Это лучше, чем ничего, но подпись с использованием секрета (а не отправка самого секрета) была бы предпочтительнее.

К сожалению, я тоже полагался на передачу секрета в заголовке. Возможно, @j.jaffeux сможет предложить более удачный вариант, который я тут же тоже приму: :sweat_smile:

Я создал шаг с кодом для вычисления подписи. Существует Web Crypto API, которое может значительно проще вычислить HMAC-SHA256, но оно использует Promise, что не работает внутри eval. Поэтому я попросил ИИ написать нативный метод на JavaScript для вычисления HMAC-SHA256, добавил переменную с ключом secret и значением-секретом (, и в итоге получил скрипт Code, похожий на этот:

// Доступные переменные:
//   $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-битной длины сообщения в формате big-endian.
    // Целые числа 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
};

За этим следует шаг HTTP-запроса с заголовком, ключ которого X-Discourse-Workflow-Secret, а значение {{ $("Code").item.json.signature }}, тип содержимого JSON, а тело запроса {{ $("Code").item.json.payload }}.

В результате получается 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-Secret: sha256=9ad2820b545013bdd18d4e7e6139624b91f576498e528201fa7759ec58dd598c

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

X-Discourse-Workflow-Secret — это подпись HMAC-SHA256, использующая значение аргумента secret… прямо как подписанный вебхук! :slight_smile:

Возможно, это и не очень красиво, но похоже, что всё работает.

Выглядит довольно солидно! Спасибо, что поделились!

Для справки: я протестировал этот нативный HMAC-SHA256 на соответствие Web Crypto API, чтобы убедиться, что для случайных сообщений и ключей результаты совпадают, и подписи оказались идентичными. Я не могу гарантировать, что не существует каких-либо особых случаев, в которых они расходятся, но меня это вполне устраивает для использования в продакшене. :slightly_smiling_face: