TWiki/UI/Manage.pm
contains the following:
# check permission, user authorized to create webs?
# TWiki::UI::checkAccess( $session, $webName, $topicName,
# 'MANAGE', $session->{user} );
#hack due to late realisation of hacking possibility
This means that
WEBMANAGE
is useless. This requires a proper fix, either in the code, or in the doc which describes
WEBMANAGE
.
CC
The complexity here comes from hierarchical wbs.
MANAGE
is just not useful any more. The ability to create a web needs to be deetrmined by examining the access to the containing web. For example, if a user wants to create
Projects.Wheel.Bicycle
, then
CHANGE
on
Projects.Wheel
should determine their rights.
Just for a moment, let's disregard the distinction between
WEB
and
TOPIC
ACLs, and focus on the meaning of
CHANGE
. If I am changing a topic, I need
CHANGE
permission on the topic. If I am creating a new topic, or creating a subweb, I need
CHANGE
permission on the containing web. If I am creating a root web, I need
CHANGE
permission on some yet-to-be-invented root level (call it
ROOT
). Currently we have no way of expressing the permissions on this superweb level. Historically, this is what
MANAGE
did, but it is really obscure.
Since
MANAGE
has effectively disappeared, I don't propose re-implementing it; let's take the opportunity to do something a bit more consistent and intention-revealing. Taking the levels
WEB
and
TOPIC
, it seems natural to add
ROOT
as a third level.
So I propose that the permissions evaluation order change as follows (changes
italicised):
- If the user is a super-user
- If web and topic are defined and
DENYTOPIC
is set to a list of wikinames
- people in the list will be DENIED.
- If web and topic are defined and
DENYTOPIC
is set to empty (i.e. Set DENYTOPIC =)
- access is PERMITTED i.e no-one is denied access to this topic
- If web and topic are defined and
ALLOWTOPIC
is set
- people in the list are PERMITTED
- everyone else is DENIED
- Note that this means that setting
ALLOWTOPIC
to empty denies access to everyone except admins (unless DENYTOPIC
is also set to empty, as described above)
- If web is defined and
DENYWEB
is set to a list of wikinames
- people in the list are DENIED access
- If web is defined and
ALLOWWEB
is set to a list of wikinames
- people in the list will be PERMITTED
- everyone else will be DENIED
- Note that setting
ALLOWWEB
to empty denies access to everyone except admins
- If web is not defined and
DENYROOT
is set to a list of wikinames
- people in the list are DENIED access
- If web is not defined and
ALLOWROOT
is set to a list of wikinames
- people in the list will be PERMITTED access
- everyone else will be DENIED access
- If you got this far, access is PERMITTED
The call in Manage.pm would become
# check permission, user authorized to create web here?
my $parent = undef; # default is root if no parent web
if( $webName =~ m|^(.*)[./](.*?)$| ) {
$parent = $1;
}
TWiki::UI::checkAccess( $session, $parent, undef,
'CHANGE', $session->{user} );
Note that this requires careful examinataion of all existing calls to
checkAccess
to ensure consistency with the "undef topic means web access" and "undef web means root" rules. This examination is long overdue anyway.
CC
Exhausting, but at least it's done.
CC
Updated headline for release notes
KJL
4.1.0 released
KJL