On 3/19/07, Thomas Arthur Oehser <[email protected]> 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