JSON RPC 2.0: нарушают ли дополнительные поля в объектах запроса спецификацию? - PullRequest
Новая
       33

JSON RPC 2.0: нарушают ли дополнительные поля в объектах запроса спецификацию?

0 голосов
/ 09 марта 2019

Я пишу JS RPC-библиотеку. Разрешено ли в спецификации клиентам добавлять настраиваемые поля (например, headers) вдоль поля params к Request объектам?

* 1006 Е.Г. * 

{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "headers": { "original-client": 12 }, "id": 1}

В спецификации (https://www.jsonrpc.org/specification#request_object) ничего не говорится о добавлении дополнительных полей.

Моя библиотека нарушает спецификацию, если добавляет поле header?

1 Ответ

1 голос
/ 05 апреля 2019

Тот же вопрос здесь.(Я хочу добавить информацию об аутентификации пользователя / подпись сообщения ...)

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

С другой стороны, я нашел здесь по крайней мере одну справочную реализацию: www.simple-is-better.org / rpc /jsonrpc.py , который поразит вас исключением, если декодированное сообщение содержит дополнительные поля.Этот код принадлежит одному из авторов спецификаций JSON-RPC 2.0 Роланду Коблеру.

Итак, YMMV.

  • Если ваша библиотека является только внутренним строительным блоком для проприетарного объектасистема, продолжайте.
  • Если вам нужно взаимодействовать с другими реализациями JSON-RPC, протестируйте каждую из них.
  • Если библиотека предназначена для публичного использования, не делайте этого.

Редактировать: я решил это, используя следующий протокол:

  • Перед сообщением "полезная нагрузка" отправьте стандартно-совместимое уведомление методом "rpc.secinfo",(Префикс rpc. является для каждой спецификации зарезервированным для расширений)
  • Поле "params" содержит все применяемые метаданные (например, имя пользователя, подпись)
  • Пример: {"jsonrpc": "2.0", "method": "rpc.secinfo", "params": {"user":"root", "signature":"0xDEADBEEF"}}<DELIM><payload><DELIM>
  • Если данные заголовка пусты, специальный метод не претендует (т. Е. Ведет себя точно так же, как стандартный json-rpc).

Получатель может декодировать сообщение заголовка, как любой другой вызов, и ему просто нужноприменить (проверьте sig, что угодно) заголовок к следующему сообщению.

Обсуждение:

  • позволяет кадрировать без касания полезной нагрузки
  • позволяет декодировать заголовок без декодирования полезной нагрузки
  • позволяет использовать байтовую полезную нагрузку как есть, в частности, позволяет сосуществовать зашифрованная + буквенная полезная нагрузка (однако зашифрованная полезная нагрузка нарушает JSON-RPC-компат!)
  • Получатель «незнающий»: вызовет вызовы rpc.secinfoтихо или громко, но может работать.Отсутствующий идентификатор указывает на уведомление, то есть получатель не будет отправлять ответ обратно согласно спецификации JSON-RPC.
  • Отправитель «не знает»: полученные сообщения действительны, сообщения без заголовка.

Feelможете повторно использовать этот протокол, но, пожалуйста, отметьте этот SO ответ.

...