Given that I just recently registered and I'm not a "committer" (yet) I assume I should not have programming Access rights. Unfortunately, it let me perform the actions anyways as if I did have these rights. I think it's only a problem of display -> basically, you cannot create new jobs (this would add groovy code to the page and indeed require programming rights, which you do not have).

However, there must be a missing check before the button you hit (something akin to #if ($xwiki.hasAccessRight('program') == 'true') button #end). So this is a bug in the watchlist application rather than in the rights setting of the wiki. I think that had you tried the .../bin/delete/... URL you would have received a "you do not have the rights to perform this action" message. In the worst case, the page wouldn't have get lost thanks to the recent restore page feature ; -) <snip> This is despite the printed warning at the bottom of the page: "Job creation is reserved for programmers. It seems you do not have programming access right allowed on the Scheduler space." The last version of the watchlist was released a few days ago, meaning there is probably some testing remaining. Please report this bug in JIRA (http://jira.xwiki.org/) so that it can be fixed by the watchlist app developer. Xwiki.org says it's running "1.3-rc-1.8082" --------------------------- This leads me to wonder how such administrative functions are secured. It makes sense to condition presentation of pause/delete/ unschedule /schedule on whether Administrative/programming-access is available to the logged-in user. (i.e. don't present UI capabilities which aren't accessible to the given login/role). However, if someone were to just enter the URL http://www.xwiki.org/xwiki/bin/view/Scheduler/?do=pause&which=Scheduler… the action should be access-controlled and prevented anyways. In my case, it wasn't. We absolutely agree on this. Most of the time XWiki has script that checks the user rights prior to displaying specific parts of the UI (for instance on the topbar menu -> the menu is not the same depending on the user being logged in as a reader, an admin...) Anyways, sorry about doing this by accident. Hopefully no damage was done (I did resume the job i paused). I assume this is a "bug" I've discovered, and not a "feature." Then it means you'll have the joy and priviledge of playing with our JIRA instance soon ;-) I guess further explorations in this area should be done on my own instance rather than xwiki.org .... ( no, i didn't test "unschedule" or "delete" given the potential that they'd actuallty work). Thanks ! :-) If you really want to test XWiki online you can use http://playground.xwiki.org/xwiki/bin/view/Main/ instead (it's almost always running on the latest version of XWiki) If this is a bug, it would probably make good sense to review other instances where this might happen (aka "security walkthrough" of code). Is there any automated functional testing of the entire system (as opposed to unit testing) to ensure such access control issues aren't lurking in other areas? We're always working on adding new tests. Your help would be greatly appreciated in this area should you have the possibility to write some of them. I'll let someone else tell you whether this one in particular already exists. -- Niels. http://nielsmayer.com PS: Is there a document describing the security architecture of Xwiki? I didn't found it on XWiki.org, meaning someone will have to write it. If you feel like it, you can start one at http://dev.xwiki.org/xwiki/bin/view/Drafts/ if you want to. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs