19 Mar
2007
19 Mar
'07
1:01 p.m.
Regarding 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
--
http://purl.org/net/sergiu
19 Mar
19 Mar
1:08 p.m.
New subject: [xwiki-dev] [Proposal] Add the 'unrestricted' access right
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" tha is
used only by them and is unrestricted, and the rest should still have a
view-protected skin.
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.
-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
References
Visible links
1. http://jira.xwiki.org/jira/browse/XWIKI-929
2. http://purl.org/net/sergiu
--
You receive this message as a subscriber of the xwiki-dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
--
May 4, 1970: Alison Krause, Jeffrey Miller, Sandra Scheuer, William Schroeder.
1:22 p.m.
New subject: [xwiki-dev] [Proposal] Add the 'unrestricted' access right
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
6391
days inactive
6391
days old
2 comments
2 participants
participants (2)
-
Sergiu Dumitriu -
Thomas Arthur Oehser