• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

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. frown

-- 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

ItemTemplate
Summary REST handlers have bad security implications
ReportedBy TWiki:Main.CrawfordCurrie
Codebase ~twiki4
SVN Range Sat, 03 Jun 2006 build 10450
AppliesTo Engine
Component

Priority Urgent
CurrentState Closed
WaitingFor

Checkins 11693 11694
TargetRelease minor
Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2007-01-16 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback