REST handlers cause initPlugin with useless web.topic
If you define a REST handler, then initPlugin gets called when the REST function is invoked. However the $web and $topic params to the initPlugin are
not valid web.topic names.
It's reasonable that some REST calls will not pass in this info, in which case the plugins should be passed (undef, undef). It is
unreasonable that they should be passed something completely different!
CC
a potentially bad side effects of this is that implicit permission checking, which might reasonably assume that WEB and TOPIC as set in initPlugin are the selected topic, get applied form the wrong place, showing / editing a topic that it shouldn't.
-- SD
this is not a suggestion to reverse the URL sematics, as that would be un-RESTFUL, but rather to fix the rest script to set web and topic from a standard web.topic parameter..
-- SD
Another problem makes me think that the current implementation is unsuitable for any operation that saves data. If you are using apache auth, its too simple to create a rest handler that bypasses that auth. (because rest is un-authed by default, and it makes sense to have an unauthed rest script too).
I've been re-writing all my restHandlers to use beforeSaveHandler, so that I am ensured of having the same authorisation senarios as a normal topic save.
TODO: we should suppliment the docco adding that using restHandlers to modify topics can lead to un-authorised saves, and add a mandatory web.topicname parameter, that the rest script checks for authorisation prior to calling a restHandler.
-- SD
This is currently a
ReleaseBlocker. What is left to do (no checkins yet) / should it be taken out / written up in
TWiki:Codev.WhatIsIn04x01?
--
SP
Fixed the REST interface for the issues dewcribed above. Of course it is still possible to bypass auth, but with such a low level interface that's always going to be a problem. At least I added support for logging in.
CC
4.1.0 released
KJL