Christian, probably easier to you is to change user profiles using velocity (and Groovy) scripts Get list of users according to platform.xwiki.org/xwiki/bin/view/DevGuide/velocityHqlExamples#HGettingobjectsofaspecificclass then change rights properties, following http://platform.xwiki.org/xwiki/bin/view/DevGuide/APIGuide#HAccessobjectsina... If you want to set these changes after new user is created automatically, you can add listener which changes object. http://platform.xwiki.org/xwiki/bin/view/DevGuide/GroovyNotificationTutorial Valdis
Hi Valdis, see my comments below and thanks for your contribution to this topic !
On 8/6/2013 03:29, Valdis Vītoliņš wrote:
We could argue, that if user has learned to use advanced edit mode, then he probably knows what he is doing (because actually he can only mess his own profile only without hurting others). Well that's not true, using advanced edit mode, user can mess up any page that he can edit up to deleting it... And for a wiki, that means pretty much any page.
I am trying to setup a public wiki and this scenario is a nightmare, because if it's possible, it's bound to happen. I dont want to wake up one day with the whole wiki being in the recycle bin...
And there is a lot of other way to mess up the wiki once the user is in advanced edit mode...
But for more strict case, I had simple workaround, by setting user profile to read-only, when profile is created by external authentication: ... BaseObject userObj = userDoc.getObject("XWiki.XWikiUsers"); ... // set user profile to read-only, to not allow changing his // name and surname BaseObject rightsObj = userDoc.getObject("XWiki.XWikiRights", 1); rightsObj.set("allow", 0, context); ... See more in http://odo.lv/git/munixwiki/tools/xwiki-authentication-sts/
Thanks for the snippet, will help me figure out how to do this properly !
Of course, user then loses ability to change his e-mail and other valuable but not identity related fields, but for this application it was not so important.
Ya it's not an issue for me either, as all info is synced from a main system but there are a few wiki prefs that it would be nice to still have. Denis mentioned the use of sheets to better to let people edit specific fields, I will look into that.
Ideally read-write/read-only for profile's owner identity-related and other fields could be parametrized in xwiki.cfg or WebPreferences page.
Or an ACL at the field level...
Valdis
Hi everyone,
I have played some more with Xwiki over the week-end, and some security issues came up, namely:
1) User own profile:
Any given user has the right to edit his own profile, so far so good when the given user is in normal mode and the edit defaults to the inline form. Now things get ugly when he switches to the advanced mode and suddenly can add/update/delete objects and rights. For example he can delete his Xwiki.users object and instantly completely break his account. He can mess up with permissions, like granting others permissions to his profile.
I am using a custom authentication/sso mechanism and when I create the user on the fly, I among other things, store the userId from our system into the XWiki.users (added one Int property). Suddenly, the user can even change that value...
He can also rename his profile, effectively renaming his username... which in a sandbox environment might not be too much of an issue, even if I find it a little weird that users can change their identity on their owns as often they want but when the wiki system in coupled with another system, it's just a disaster...
2) User in advanced mode
Generally speaking, users in advanced mode seems to be able to do things that I didnt foresee with just the edit permission : - I could grant myself the delete permission on pretty much any page I have edit permission and therefore deleting the pages - I could add/update/delete pretty much any objects on any page I have edit permission including XWiki.XWikiRights instances which seems to cover the ACL specific to the page. I granted there myself programming rights, it does not seem to work however the ACL is saved just fine...
Regarding the ACL, I strongly suggest that on the Access Rights page, when the permission is blank (delegating upstream), the given permission should be still visible (with a tooltip indicating from where the permission has been inherited), maybe in parenthesis just after the checkmark box. It is crucial that on any page/space/wiki, an admin is able to review the effective permissions of that given page/space/wiki. Otherwise, it makes reviewing permissions a nightmare really quickly.
3) HTML macro
This is more a question on the best way to make sure the HTML macro will filter out specific stuff to prevent script injection ? From what I understand, the macro cannot be removed at the moment but I am not sure what is the best way to secure it.
Regarding 1 & 2, hopefully I am overlooking something but I looked around and could not find any thing obvious. Using Xwiki Enterprise 5.1
Thanks in advance for your help !
-- Chris
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs