On 3/19/07, Thomas Arthur Oehser <tom@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:
> 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
>