19 Mar
2007
19 Mar
'07
1:22 p.m.
On 3/19/07, Thomas Arthur Oehser <tom(a)toms.net> wrote:
I think that normally this is mostly a special case for registration and
login and such, and that the "normal" skins should still be
view-protected, that is, when the "unrestricted" right is supported, the
default configuration should have a "loginAndRegistrationSkin" that is
used only by them and is unrestricted, and the rest should still have a
view-protected skin.
Doing things like this is bad. I also thought of forcing the use of the
filesystem skin when the default skin is not accessible, but I don't like
it. It is not extensible, and requires a lot of if-testing in the code.
Note, I'm also having issues with the user's own profile behaving _too_
much unrestricted, where users are allowed to add
comments to their own
page even before they have been give edit rights. This can be a huge
problem, as their own page is *usuall* where spammers put google rank
spam.
I know that you are not happy with the way access rights are working for the
moment, and I intend to review the code. Please be patient, your complains
have been heard, and they are top priority. We just lack the time to solve
all the bugs in such a short time.
Sergiu
-Tom
On Mon, Mar 19, 2007 at 02:01:06PM +0200, Sergiu Dumitriu wrote:
--
http://purl.org/net/sergiu
Regarding
[1]http://jira.xwiki.org/jira/browse/XWIKI-929
XWikiRightsServiceImpl list several categories of access rights:
view,
edit, comment, delete, register, admin,
programming. Each action is
mapped
to one of these categories. For example,
/viewrev/ is a 'view'
action,
/propupdate/ is an 'edit' action.
Currently, the most permissive right is "view", but some actions need
an
even more permissive right. For example, if
the wiki requires
authentication for viewing, then the skin will not be displayed.
We should add a new access right class, "unrestricted", which cannot
be
used in the Access Rights Editor, but is used
internally to allow
some
actions to always be executed, regardless of
the access rights of the
user.
This raises some security issues, like what if the skin really
shouldn't
be accessible? What if a plugin registers an
unrestricted action, but
nothing should be unrestricted? For this, we can do the following:
- add an option in xwiki.cfg, 'security.allow_unrestricted', which
can
disable unrestricted access; in this case
'unrestricted' behaves as
'view'.
- add an option in XWikiPreferences, which actions are allowed to
behave
as unrestricted. Although some plugins by
default register an action
as
'unres', we can force this action to
require 'view' rights.
We need to add this, a lot of users are complaining that the skin
isn't
displayed, we just have to decide how do we
secure this right.
Sergiu
--
[2]http://purl.org/net/sergiu