Christian,
probably easier to you is to change user profiles using velocity (and
Groovy) scripts
Get list of users according to
If you want to set these changes after new user is created
automatically, you can add listener which changes object.
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs