Совместимость с реализациями php и java json-rpc и поддержка ssl

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

Если, с другой стороны, вы зададите конкретные вопросы об определенных библиотеках/реализациях, вы можете получить разумные ответы. Общая проблема с этим подходом заключается в том, что спрашивающий не знает, какие вопросы задавать! (И это приводит к повторному изобретению колес и часто к неверным решениям в отношении безопасности).

Группа протоколов JSON-RPC (1.0/1.1/2.0) чрезвычайно просто. Существуют сотни реализаций PHP. Я мало что знаю об оценке библиотек Android, но это предыдущий вопрос SO дает предлагаемую реализацию на стороне клиента для Android.

В первую очередь я рассмотрю серверную часть вашего вопроса, дав вам конкретные ответы, которые вы можете задать о конкретной реализации, которую вы, возможно, оцениваете.

Рекомендации по реализации PHP JSON-RPC на стороне сервера:

1. Как вы будете обрабатывать аутентификацию транспорта?
2. Как вы будете обрабатывать авторизацию методом RPC?
3. Как вы будете обеспечивать транспортную безопасность?
4. Вам нужно будет обрабатывать позиционные/именованные/оба аргумента метода стиля
5. Вам нужно будет обрабатывать/отправлять уведомления?
6. Вам нужно будет обрабатывать пакетные запросы? Потребуется ли вам отправлять пакетные ответы?
7. Как ведет себя реализация PHP при различных условиях исключений/предупреждений?
8. Как реализация PHP предостерегает или смягчает двойственность набора/списка массива PHP?
9. Нужно ли будет внедрять SMD?
10. Потребуется ли вашему веб-сервису также выполнять другую маршрутизацию на уровне HTTP? (например: к статическим ресурсам)

Как вы будете обрабатывать аутентификацию транспорта?

Предполагая, что вы используете HTTP в качестве протокола транспортного уровня, как вы будете аутентифицировать HTTP-запросы? Будете ли вы использовать пароль/HTTP-авторизацию/сертификат/SRP/другую аутентификацию? Будете ли вы продолжать доверять открытому сокету? Будете ли вы использовать файлы cookie для расширения доверия после аутентификации?

На самом деле это не вопросы, связанные с JSON-RPC, но многие реализации на стороне сервера делают всевозможные предположения о том, как вы будете выполнять аутентификацию. Некоторые просто оставляют это полностью на ваше усмотрение. Ваш выбор библиотеки, вероятно, во многом зависит от вашего выбора здесь.

Как вы будете обрабатывать авторизацию методом RPC?

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

Хотя эти проблемы находятся внутри оболочки JSON-RPC, они не рассматриваются напрямую в спецификациях протокола JSON-RPC.

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

Как вы будете обеспечивать транспортную безопасность?

Предполагая, что вы используете HTTP в качестве протокола транспортного уровня, очевидным ответом на этот вопрос будет TLS. Здесь применимы все обычные проблемы безопасности SSL/TLS, и многие вопросы SE/SO уже связаны с ними.

Поскольку вы контролируете реализацию на стороне клиента, вы должны, по крайней мере, учитывать:

• Выбор надежного шифра и запрещение плохих шифров
• Разумно вести (или не иметь дело!) с повторными переговорами
• Избегайте известных проблемных реализаций/функций (например, OpenSSL 1.0.1-1.0.1f, heartbeat[CVE-2014-160]).

Вам нужно будет обрабатывать позиционные/именованные/оба аргумента метода стиля

Некоторые серверные реализации JSON-RPC предпочитают, чтобы аргумент params оболочки JSON-RPC выглядел как params: [412, "something"] (позиционный), в то время как другие предпочитают, чтобы аргумент params оболочки JSON-RPC выглядел как params: { "type": "something", "num_events": 412 } (именованный). Третьи могут работать с любым стилем без проблем. Ваш выбор клиентских и серверных библиотек должен основываться на этом вопросе «совместимости».

Вам нужно будет обрабатывать/отправлять уведомления?

Сообщения Notification отправляются клиентом или сервером противоположной стороне, чтобы сообщить некоторые обновленные /завершенное состояние с течением времени. Отправляющая сторона (якобы) не должна ожидать ответа на сообщение «уведомление».

Большинство реализаций JSON-RPC используют HTTP(S) в качестве транспортного протокола; поскольку HTTP не реализует двунаправленную асинхронную связь, вы не можете правильно реализовать сообщения «уведомления».

Поскольку вашей клиентской частью будет Android, вы можете использовать простой текст JSON через сокеты TCP в качестве транспортного протокола (а не HTTP); поскольку TCP разрешает двустороннюю асинхронную связь (после установления сокета), вы можете правильно реализовать "уведомляющие" сообщения.

Некоторые библиотеки реализуют уведомления от клиента к серверу через HTTP-транспорт, помещая сообщения уведомлений в очередь, а затем объединяя уведомления в сообщениях в стиле запроса (возможно, используя "пакетные" запросы - см. следующий вопрос). Точно так же некоторые библиотеки реализуют уведомления от сервера к клиенту через HTTP-транспорт, встраивая уведомления в сообщения в стиле ответа (возможно, используя «пакетные» ответы).

Другие библиотеки используют HTTP, используя WebSockets в качестве своего транспортного протокола. Поскольку это позволяет осуществлять двустороннюю (по существу) асинхронную связь, эти библиотеки могут правильно реализовывать "уведомляющие" сообщения.

Если вам это не нужно, у вас будет значительно больший выбор транспортных протоколов (и, следовательно, реализаций).

Вам нужно будет обрабатывать пакетные запросы? Потребуется ли вам отправлять пакетные ответы?

Иногда желательно отправлять/обрабатывать группы запросов/ответов/уведомлений в одном запросе/ответе (так называемый "пакет" сообщений). Аргумент id конверта JSON-RPC используется для различения запросов и ответов в пакете.

Если вам это не нужно, у вас будет значительно больше выбора при выборе реализаций («пакетные сообщения» — это наиболее часто пропускаемая функция реализаций JSON-RPC).

Как ведет себя реализация PHP при различных условиях исключений/предупреждений?

В PHP есть много способов передать программисту условия ошибки, а также различные типы условий ошибки. Обрабатывает ли реализация на стороне сервера «выброшенные» исключения и ошибки на уровне PHP согласованным образом? Подходит ли конфигурация error_reporting (и меняет ли ее локально библиотека)? Будет ли библиотека плохо взаимодействовать с библиотеками отладки (например, xdebug)?

Изолирует ли серверная реализация ошибки уровня JSON-RPC от ошибок уровня HTTP? (т. е. предотвращает ли он превращение ошибок/исключений внутри жизненного цикла запроса в ошибку уровня HTTP, например 500: Internal Server Error).

Правильно ли взаимодействует серверная реализация с вашими мерами аутентификации и авторизации? (т. е.: может быть желательно перевести связанные ошибки в статусы HTTP 401: Unauthorized и 403: Forbidden соответственно).

Пропускает ли серверная реализация конфиденциальную информацию о вашей реализации или источниках данных при доставке ошибок либо через HTTP, либо через JSON-RPC?

Это довольно важные вопросы, которые следует задать веб-сервису JSON-RPC, который будет использоваться в условиях безопасности. Довольно сложно оценить это для данной реализации, прочитав ее документацию. Вам, вероятно, потребуется:

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

Как реализация PHP предостерегает или смягчает двойственность набора/списка массива PHP?

PHP — дерьмовый язык. Там. Я сказал это :-)

Одна из распространенных проблем, с которой сталкиваются разработчики JSON-RPC, заключается в том, как правильно сопоставить JSON arrays и JSON objects с собственными структурами данных языка. В то время как PHP использует одну и ту же структуру данных как для индексированных, так и для ассоциативных массивов, в большинстве языков это не так. Это включает в себя JavaScript, чьи языковые особенности/ограничения учитывались в спецификациях JSON (и, следовательно, JSON-RPC).

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

Одним из распространенных способов смягчения последствий является то, что реализация JSON-RPC может вынудить автора привести все предполагаемо-ассоциативные массивы к (object) перед их возвратом, а затем отклонить во время выполнения любые индексированные массивы (неявные или предполагаемые), которые имеют неподтверждающие ключи или не -последовательные индексы. Некоторые другие серверные библиотеки заставляют авторов аннотировать свои методы, чтобы предполагаемая семантика массива была известна во время «компиляции»; некоторые пытаются определить набор текста с помощью автоматического самоанализа (плохо, плохо, плохо). Тем не менее другие сторонние библиотеки оставляют это на волю случая.

Смягчения, присутствующие/отсутствующие в реализации PHP JSON-RPC на стороне сервера, вероятно, будут весьма показательны в отношении ее качества :-)

Нужно ли будет внедрять SMD?

SMD — это не очень стандартизированное расширение JSON- RPC-подобные протоколы, позволяющие публиковать WSDL-подобную информацию о конечной точке веб-сервиса и функций (никаких классов, хотя там можно найти соглашения по пространствам имен), которые он предоставляет.

Иногда проблемы «ввода» и «авторизации» накладываются на «аннотации» класса/функции, используемые для реализации SMD.

Этот «стандарт» плохо поддерживается ни в клиентских, ни в серверных реализациях :-)

Потребуется ли вашему веб-сервису также выполнять другую маршрутизацию на уровне HTTP? (например: к статическим ресурсам)

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

Вы часто можете обойти эти проблемы, перенаправляя известные запросы JSON-RPC на отдельный веб-сервер или направляя запросы, отличные от JSON-RPC, на отдельный веб-сервер.

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