Item13969: rest and jsonrpc scripts should default the web/topic if -topic query param is not provided
Priority: Enhancement
Current State: Proposal Required
Released In: 2.2.0
Target Release: minor
MichaelDaum pointed out that we don't default a usable web/topic if rest or jsonrpc are called without the topic= query param.
Appears to be relatively easy to rectify. And SMELL in Foswiki.pm pointed out that setting web/topic to the bogus Subject/Verb from rest "did no harm". But obviously it does.
--
GeorgeClark - 23 Feb 2016
viewfile
and
xsendfile
interprete path_info differently as well ...
And this breaks
jsonrpc
as
EVERY request is evaluated agains
%USERSWEB%.%HOMETOPIC%
.
A json rpc POST request has got the format
{
jsonrpc: "<api-version>",
params: {
topic: "web.topic",
...
}
}
Adding a third
topic
parameter to the payload violates the protocol returning:
{
"jsonrpc":"2.0",
"error": {
"message":"Invalid JSON-RPC request - unknown key topic",
"code":-32600
}
}
Sorry, I thought this was easier, but we need to rethink the approach.
Basically, some actions such as
rest
,
jsonrpc
,
viewfile
and
xsendfile
interpret the
path_info
differently, i.e.
web and topic location might be specified:
- on a different spot in
path_info
: viewfile
, xsendfile
- within a json object:
jsonrpc
- as an url parameter: optional for all scripts except
rest
where it should be mandatory
- not at all: a potential script that doesn't deal with webs or topics at all.
The checkin needs a revert, unfortunately.
(Btw. this breaks
AngularSkin /
AngularPlugin as well which heavily relies on jsonrpc.)
--
MichaelDaum - 23 Feb 2016
Current state on this:
-
rest
now gets a sane default basetopic if topic= urlparam is missing.
- The parser for
viewfile
/ xsendfile
is still broken. mis-identifies attachment as topic
- I did some testing of the Foswiki::Address parser with hinting enabled. It is also broken, but fix is pretty simple. However Foswiki::Address has been removed from master.
-
jsonrpc
has no sane default topic, and depends on a bug in the parser to get that way.
--
GeorgeClark - 10 Mar 2016
I have some ideas on how to address
jsonrpc
The issue is that jsonrpc needs to process the data in the request early, before the baseweb / basetopic has been established, (and before the Foswiki SESSION object has initialized. If we were add to the
SwitchBoard
an earlyInit which runs before the
Foswiki->new()
is called.
$Foswiki::cfg{SwitchBoard}{jsonrpc} = {
package => 'Foswiki::Contrib::JsonRpcContrib',
function => 'dispatch',
initFunction => 'init', # Establish context & env based upon json request.
context => { jsonrpc => 1 },
};
This won't be backwards compatible with Foswiki 1.x / 2.0 / 2.1, but the results is that init won't be called, and foswiki will establish the current "broken" web/topic, so it will not be any worse than it is currently.
I think it would be called in
lib/Foswiki/UI.pm
, around line 326, just before it calls
_execute()
. It would return a replacement context hash for use during initialization.
contxt = { jsonrpc => 1,
webtopic => (web.topic from json request),
};
Foswiki.pm would then examine the "initialContext" and use it to set the web/topic.
- If initialContext contains webtopic, use it,
- else if query param -topic=webtopic,
--
GeorgeClark - 14 Mar 2016
See
MoveQueryPathParsingIntoFoswikiRequest. Fixing jsonrpc is more than a quick hack to Foswiki.pm. Marking this as a 2.2 but might even be a 3.0 feature.
--
Main.GeorgeClark - 20 Mar 2016 - 22:34