Несоответствие кодировки хэша полезной нагрузки DiscourseConnect

Поддержка SSO
3

Я ещё не тестировал это на своём сайте, сначала пытаюсь вручную разобраться в шагах.

Из упомянутого ранее сообщения на форуме:

При следующих настройках:
Домен Discourse: http://discuss.example.com
URL DiscourseConnect: http://www.example.com/discourse/sso
Секрет DiscourseConnect: d836444a9e4084d5b224a60c208dce14

Попытка входа пользователя

  • Сгенерирован nonce: cb68251eefb5211e58c00ff1395f0c0b
  • Сгенерирован исходный payload: nonce=cb68251eefb5211e58c00ff1395f0c0b
  • Payload закодирован в Base64: bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI=\n
  • Payload закодирован в URL: bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGI%3D%0A
  • Сгенерирован HMAC-SHA256 для payload в Base64: 2828aa29899722b35a2f191d34ef9b3ce695e0e6eeec47deb46d588d70c7cb56

Здесь я получаю другой результат. Когда я использовал HMAC-кодер, который вы предложили, для payload в Base64 без URL-кодирования, я получил d26d5adf900de48890a0c3dcdeec108acd91b44a4b76c90c59955a5ba7b957f7 вместо 2828aa29899722b35a2f191d34ef9b3ce695e0e6eeec47deb46d588d70c7cb56. Когда я использовал его для payload с URL-кодированием, я получил 46e749cd26dcabc84eed323ff31f830da674dc87c77a2fcb1b296f76402ea900.

Однако позже в руководстве, при создании нового payload:

Сгенерирован неподписанный payload:
nonce=cb68251eefb5211e58c00ff1395f0c0b&name=sam&username=samsam&email=test%40test.com&external_id=hello123&require_activation=true
(порядок не важен, значения закодированы в URL)

Payload закодирован в Base64:
bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ==

Payload закодирован в URL:
bm9uY2U9Y2I2ODI1MWVlZmI1MjExZTU4YzAwZmYxMzk1ZjBjMGImbmFtZT1zYW0mdXNlcm5hbWU9c2Ftc2FtJmVtYWlsPXRlc3QlNDB0ZXN0LmNvbSZleHRlcm5hbF9pZD1oZWxsbzEyMyZyZXF1aXJlX2FjdGl2YXRpb249dHJ1ZQ%3D%3D

Payload в Base64 подписан:
3d7e5ac755a87ae3ccf90272644ed2207984db03cf020377c8b92ff51be3abc3

Эта подпись генерируется путём хеширования payload в Base64 без URL-кодирования, поэтому я немного не понимаю, почему это не работает для первого payload.