Hi Trevor,
I just want to complete what Guillaume had said.
For any documents it exists 2 authors:
- the last _author_ of the document, the one that have saved any
information into the document
- the last _content author_ of the document, the one that have saved
the _content_ of the document
The first one is show in the about div at the bottom of each document,
the second one is very hidden and could only be checked in an XAR
export, a raw XML view of the document or using code.
For some operations, like accessing the internal privileged API from
velocity or running groovy scripts, the _content author_ of the
document containing the (velocity) code (or the one your are looking
at for groovy) should have programming rights. Currently, with the new
rendering engine, the document on which the content author is checked
is always the document your are looking at, not necessarily the one
that directly contains the code. This should be improved later, when
the new 2.0 macros received more context information.
Therefore, the rights to do an operation has usually nothing to do
with the programming rights of the currently connected user. AFAIK,
there is almost no case where the currently connected user is check
against programming rights in a standard XWiki.
So most of the page of a basic XWiki does not require such rights,
some does. And due to the way new wikis are setup, generally by an
import procedure, there may be additional issues, regarding
programming rights:
- most pages has XWiki.Admin as content author at initial stage
- in a farm, those having XWiki.Admin as content author in another
wiki than the main one, does not have programming rights (XWIKI-4066)
- importing non-backup pack does not help in fixing content authors
(XWIKI-3725)
So this is currently a bad idea to remove XWiki.Admin, and I generally
change its password to some random one for securing that somewhat
internal account.
As Guillaume said, there is room for improvement:
- ensure proper context for 2.0 macros (in progress I think)
- ensure better support of content authors during import
(XWIKI-3725, XWIKI-4066, XWIKI-4073)
- allow importing backup pack (like the XWiki provided ones) as non-
backup one, this would allow importing non-backup pack with another
admin as content author
- it could also be useful for admin to see who is the content author
more easily, since there is no interface showing them
Hope that this will help you understanding potential programming issues.
Regards,
Denis
On 24 août 09, at 17:37, Guillaume Lerouge wrote:
Hi Trevor,
On Mon, Aug 24, 2009 at 5:06 PM, Trevor <tr.wiki(a)telus.net> wrote:
In setting up our XWiki farm, I came across a
couple of bugs.
In general, should we always bring up bugs on the mailing list
first before
entry into jira?
I deleted the account named "Admin" after setting up other
individuals as
administrators. A user with "admin" rights (or even "delete"
rights) could
no longer create or delete wikis from the "wikis" page of the XEM.
However,
if I recreated an account named "Admin", then a user with "admin"
rights
*could* create/delete wikis from that page, even though they're not
logged
in as user "Admin".
The rights checking on that page must be hardcoded to check if user
"Admin"
has the rights, instead of checking the user who's actually logged
in and
making the page request.
XEM 1.9.3
That's most probably due to a programming rights issue. In XWiki,
certain
pieces of code (namely Groovy code) can be executed only if the last
user to
have saved the document where such code is stored has programming
rights.
This is to prevent arbitrary code execution and privilege escalation
in the
wiki.
If I'm correct, all you need to do after deleting the "Admin"
account is to
save the page where the Groovy code is stored with one of your other
admins,
after making sure that admin has the programming right set as true
at the
global level of your farm.
We're aware that the way this mechanism works is not ideal in cases
such as
yours and we'll fix its logic at one point, but for the time being
that's
how things work.
So it's not quite a bug but I agree there's room for improvement.
As for discussing issues on the mailing lists before posting on
JIRA, well,
the discussion will take place in JIRA comments if it has to
anyway ;-)
Thanks for your feedback,
Guillaume
Trevor
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users