Any movement on this? I can't seem to get jsonrpclib to force parameterized
queries. Replicating this is fairly simple:
1. Create a new app, in default.py add a function. Replace t_test with auth or
whatever:
@service.jsonrpc
def list():
data = db(db.t_test.ALL).select()
return dict(data=data)
2. Drop to a python shell:
>>> import jsonrpclib
>>> j =
>>> jsonrpclib.Server(uri='http://localhost:8000/appname/default/call/jsonrpc')
>>> j.list()
Traceback (most recent call last):
File "<input>", line 1, in <module>
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/jsonrpclib/jsonrpc.py",
line 276, in __call__
return self.__send(self.__name, kwargs)
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/jsonrpclib/jsonrpc.py",
line 225, in _request
check_for_errors(response)
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/jsonrpclib/jsonrpc.py",
line 529, in check_for_errors
raise ProtocolError((code, message))
ProtocolError: (100, u'TypeError: list() argument after ** must be a mapping,
not str')
Same problem with simplejsonrpc in gluon/contrib...
Niphlod wrote:
> uhm. The "problem" is that even though every jsonrpc interface I
> worked with was parameter-based, for jsonrpc2 position-based and
> parameter-based are both valid.
>
> On Tuesday, December 11, 2012 10:42:06 PM UTC+1, Jonathan Lundell wrote:
>
> On 11 Dec 2012, at 1:09 PM, Niphlod <[email protected]
> <javascript:>> wrote:
>> I took some time to watch at the jsonrpc specs. Right now I had
>> experience with jsonrpc only in the "named parameters" format. I
>> thought it was the standard, my bad.
>> However, I found out that 2.0 introduced "named parameters" that
>> were not supported - explicitely - in 1.0
>>
>> --> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
>> <-- {"jsonrpc": "2.0", "result": 19, "id": 1}
>>
>> --> {"jsonrpc": "2.0", "method": "subtract", "params": {"subtrahend":
>> 23, "minuend": 42}, "id": 3}
>> <-- {"jsonrpc": "2.0", "result": 19, "id": 3}
>>
>> are both valid.
>>
>> Maybe revert this and make a jsonrpc2 decorator to support named
>> parameters explicitely would be a better solution?
>
> How about both jsonrpc1 and jsonrpc2, and then jsonrpc = jsonrpc2?
> (I think it'd be better to make v2 the default.)
>
>>
>> On Tuesday, December 11, 2012 9:57:50 PM UTC+1, Kurt Grutzmacher
>> wrote:
>>
>> I don't think this is a good JSON-RPC example as the change
>> broke our app that uses simplejsonrpc or jsonrpclib to make
>> API calls.
>>
>> Based on the jsonrpclib python module
>> @ https://code.google.com/p/jsonrpclib/
>> <https://code.google.com/p/jsonrpclib/> requests look like:
>>
>> >>> import jsonrpclib
>> >>> server = jsonrpclib.Server('http://localhost:8080
>> <http://localhost:8080/>')
>> >>> server.add(5,6)
>> 11
>> >>> print jsonrpclib.history.request
>> {"jsonrpc": "2.0", "params": [5, 6], "id": "gb3c9g37", "method":
>> "add"}
>> >>> print jsonrpclib.history.response
>> {'jsonrpc': '2.0', 'result': 11, 'id': 'gb3c9g37'}
>>
>>
>> And the JSON-RPC spec states params should be "An Array of
>> objects to pass as arguments to the method."
>> -- http://json-rpc.org/wiki/specification
>> <http://json-rpc.org/wiki/specification>
>>
>> However the actual spec doesn't specify array, dict or
>> whatever as it tries to be universal: "A Structured value
>> that holds the parameter values to be used during the
>> invocation of the method. This member MAY be omitted."
>> http://www.jsonrpc.org/specification#request_object
>> <http://www.jsonrpc.org/specification#request_object>
>>
>> For simplejsonrpc and jsonrpclib to work we have to undo this
>> change in gluon/tools.py
>>
>>
>> On Wednesday, November 14, 2012 1:25:22 PM UTC-8, Mike Anson
>> wrote:
>>
>> Thanks very much for your help Niphlod.
>>
>> On Wednesday, 14 November 2012 16:10:35 UTC-5, Niphlod wrote:
>>
>>
>> Yes I understand your point. The reason it is
>> currently like this is because if I use your
>> suggestion (which I obviously had originally)
>>
>> {"id": 1, "method": "savemessage", "params": {
>> "*message*": "variableholdingmessage", "*uid*" :
>> "variableholdingmail"}}
>>
>> I get message and uid as the values in the DB. So
>> I switched them.
>>
>> {"id": 1, "method": "savemessage", "params": {
>> "variableholdingmessage": "mymessage",
>> "variableholdinguid" : "myemail@localhost"}}
>>
>> The result means that variableholdingmessage is
>> saved as the message and not the expected
>> "mymessage". Exactly the same for uid.
>>
>> Unfortunately jsonrpc call method has a bug. in
>> web2py 2.2.1, in gluon/tools.py, line 4231 should be
>>
>> s = methods[method](**params)
>>
>> instead of
>>
>> s = methods[method](*params)
>>
>>
>> sending a patch to Massimo right now!
>>
>>
>>
>> re: PS -- haha yes I know. I did try it with
>> single quotes and it crapped out?? So just kept
>> the doubles. It's not that bad!
>>
>> re: PS2 -- have you any recommendations to solve
>> this special character potential problem?
>>
>>
>> Normally with jsonrpc you use something that is not
>> curl, e.g. a programming language that supports json
>> (python?!)
>> Escaping on bash without awk, sed, etc is always
>> problematic.... but if you're willing to have as only
>> limitation the " character that is less frequent to
>> use within a message, why don't you use one of the
>> methods not requiring a json body to be posted ? e.g.
>> @service.xml, @service.csv or @service.json....
>>
>> curl -v --get --data-urlencode \"uid=$uid\"
>> --data-urlencode \"message=$message\" $url
>>
>> here curl takes care of urlencoding the message and
>> the uid parameters.
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>
>
> --
>
>
>
--
