In Web 2.0-land, things really seem to be heating up with the not so interesting (or, in and of itself no more interesting than XML)
JSON and the more interesting (as a lightweight replacement for XML-
RPC or
XMLHttpRequest used in AJAX apps)
JSON-RPC to the point hat I've started tracking things on a
wiki page.
To break down, here is what is sent on the wire.
JSON-
RPC is quite similar to XML-
RPC except instead of sending and XML message via an HTTP POST you use
JSON, such as:
POST http://jsolait.net/services/test.jsonrpc HTTP/1.1
Host: jsolait.net
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Content-Type: text/plain
Referer: http://jsolait.net/wiki/examples/jsonrpc/tester
Content-Length: 99
Pragma: no-cache
Cache-Control: no-cache
{"id":"httpReq", "method":"args2Array", "params":["hello", {"a": 1234, "b": "five"}, [6, 7, 8, 9]]}HTTP/1.0 200 OKAnd obviously the server will respond with something like
HTTP/1.0 200 OK
Date: Wed, 28 Feb 2007 22:32:17 GMT
Server: Apache/2.0.55 (Debian) DAV/2 SVN/1.3.2 mod_python/3.2.10 Python/2.4.4
Content-Type: text/plain; charset=UTF-8
Proxy-Connection: close
{"id":"httpReq", "result":["hello", {"a":1234, "b":"five"}, [6, 7, 8, 9]], "error":null}
In terms of security, so far I've only found
one presentation at CCC somewhat related to
JSON-
RPC security and I didn't find it terribly interesting. This
article by Metaeye Security Group was a bit better, but had nothing to do with RPC, only JSON. Then there is the
August 2006 Working Draft we see the following as a "non-goal:"
JSON-RPC does not address security, correlation, reliability, sessions management, state management and many other features that may be found in other RPC protocols or distributed systems. Developers are instead encouraged to employ features of HTTP and related Internet technologies that can offer some of these features in an equally compelling, robust and satisfying manner. Some features may be defined as extensions by other specifications.Now it is tempting to mock this sentiment as the normal "security never makes it into 1.0 argument" (or think
TCP/
IP protocols that say, hey
IPSEC will handle all security -- or our web application is secure if it goes over HTTPS) but there is actually some sense to their logic.
In an ideal world, it would definitely be better to rely on the web [application] server, web framework (or whatever) to do session management, authorization, authentication, and definitely encryption. Why reinvent the wheel, badly? However in practice this normally means form based authentication plus a strong session ID (whether Java,
PHP, ASP, or whatever) all over
SSL. But what if I don't want that or can't have that, for example if I'm not running the client within a browser--and yes I could definitely see some use cases for non-browser based
JSON-
RPC (as an alternative to SOAP or XML-
RPC) and given the number of implementations out there some other folks obviously do as well.
Since
HTTP Digest Authentication is not a pervasive or a robust as we would like (a case in point: try to find a Python/Ruby/Java based Web Server to expose XML-
RPC web services that supports RFC 2617--actually Ruby seems the best choice) you are stuck with Basic Authentication over HTTPS. What I wish is that there were a lightweight authentication and authorization mechanism comparable to what
Amazon does with S3 and its REST
APIs.
If you are doing "
RPC stuff" over HTTP, you need more granular security mechanisms than can be provided by HTTP[S] or the
appserver.
Right now the big boys in web service land (Amazon, Google, Yahoo) don't seem to be exposing their
APIs with
JSON-
RPC yet (although they do expose data in
JSON) similar to the way that SOAP and REST are currently used, but it is probably only a matter of time. The other aspect of JSON-RPC that is sort of interesting is that several of the JSON-APIs are borrowing heavily from their XML-RPC counterparts, which have had their share of security issues--at least in PHP, Python, and Ruby.
UpdateI just ran across some fresh blogs (last week) on JSON (In)Security that are relevant:
Securing your JSON and
JSON is not as safe as people think it is.
I will continue to add stuff like this to my
Json Wiki Page as I find it.
